OpenDino d01824ba http://opendino.org/wiki/index.php?title=Main_Page MediaWiki 1.28.0 first-letter Medium Spezial Diskussion Benutzer Benutzer Diskussion OpenDino OpenDino Diskussion Datei Datei Diskussion MediaWiki MediaWiki Diskussion Vorlage Vorlage Diskussion Hilfe Hilfe Diskussion Kategorie Kategorie Diskussion 0 2 2 2013-02-04T13:59:44Z Dirk 2 Created page with "= Welcome to '''OpenOpal ''' = '''OpenOpal ''' is an '''Open''' Source software environment for '''OP'''timization '''A'''nd '''L'''earning, providing algorithms for automatic o..." wikitext text/x-wiki = Welcome to '''OpenOpal ''' = '''OpenOpal ''' is an '''Open''' Source software environment for '''OP'''timization '''A'''nd '''L'''earning, providing algorithms for automatic optimization, Design of Experiment, and Machine Learning. The software consists of a '''Core''', a Graphical User Interface ('''GUI''') and '''Module'''s. The Modules comprise all functionality such as optimization algorithm and interfaces to the problem to be optimized. OpenOpal is written in Java. To get into the project: * check the [[Screenshots | Screenshots]] to get an idea about the basic interaction with the software * then, check the [[Documentation | Documentation]]. * or simply download the executable jar (no compilation necessary) from ToDo:Link. Contact: * [mailto:help@openopal.org help@openopal.org] 0 3 3 2013-02-04T14:04:51Z Dirk 2 Created page with "== The Main Window == After starting OpenOpal, the main '''GUI''' appears (Fig. 1). The figure contains an example for an optimization using 4 '''Module'''s. Each module has a..." wikitext text/x-wiki == The Main Window == After starting OpenOpal, the main '''GUI''' appears (Fig. 1). The figure contains an example for an optimization using 4 '''Module'''s. Each module has a name and an unique ID. OpenOpal is a strictly modular software. All functionality for automated optimization and machine learning is encoded in the modules. Here: Module 1 (<code>OptAlgCMA</code>) is an optimization algorithm. It is connected via Module 3 (<code>Protocoller</code>) with Module 2 (<code>ProblemSimple</code>). Module 2 contains the optimization problem, i.e. the function to minimize. Here, it is a simple continuous, quadratic function. Module 3 (<code>Protocoller</code>) is a protocoling module, i.e. it stores all evaluated solutions of an optimization run. These solutions can be visualized with Module 4 (<code>DataViewer</code>). [[Image:OpenOpalMainGUI.png|frame|center|Figure 1: Main GUI of OpenOpal]] == Adding, Editing, and Connecting Modules == Right-clicking on the dotted area or on a module opens a dialogue as shown in Fig. 2. This dialogue supports: * adding modules (if clicked on a free space) * removing modules or changing the options of a module when clicking on a module * adding/removing connections between modules * checking and running modules In Fig. 2, the right-click is made on Module 4, e.g. for setting the options of this module. [[Image:OpenOpalModuleRightclick.png|frame|center|Figure 2: Editing Modules]] == Running an Optimization == Right-clicking Module 1 and selecting the option <code>Run</code> starts an optimization. The standard output of the optimization is given in the lower part of the main window in Fig. 3. [[Image:OpenOpalOptimization.png|frame|center|Figure 3: Running an Optimization]] == Postprocessing an Optimization == Right-clicking Module 4 and selecting the option <code>Run</code> starts an the data viewer. Figure 4 shows the evolution of the objective function ''f'' over the number of evaluations. As the objective function is a simple quadratic function (x^2), the minimal function value is zero, which is approximated by 1e-12. [[Image:OpenOpalDataViewer.png|frame|center|Figure 4: Postprocessing an Optimization with the DataViewer module. ]] == References == Input file behind screen shots is stored in the SVN repository ToDo: Link. 0 10 10 2013-02-04T14:20:58Z Dirk 2 Created page with "== Download == * [[Download | Executable]] * [[Documentation/Download/SVN | Source Code]] * [[Documentation/Software/Requirements | Software Requirements]] == Theory == * [[Doc..." wikitext text/x-wiki == Download == * [[Download | Executable]] * [[Documentation/Download/SVN | Source Code]] * [[Documentation/Software/Requirements | Software Requirements]] == Theory == * [[Documentation/DoE | Introduction to Design of Experiment]] * [[Documentation/Optimization | Introduction to Automated Optimization]] * [[Documentation/Machine_Learning | Introduction to Machine Learning]] * [[Documentation/Notation | Symbols and Notation]] == Users' Guide == * [[screenshots | A First Introduction to OpenOPAL in the Screenshots]] * [[Documentation/Installation | Download and Installation of OpenOPAL]] * [[Documentation/Modules | Module Documentation of OpenOPAL]] == Developers' Guide == * [[Documentation/Compiling/Shell | Compiling and Running the Code in a Shell/Console]] * Guidelines for Coding ** [[Documentation/coding/naming | Naming Conventions]] ** [[Documentation/coding/contracts | Contracts]] ** [[Documentation/coding/formatting | Code Formatting]] * Concepts behind OpenOpal ** [[Documentation/Modules/Execution | Module Execution]] ** [[Documentation/Modules/IModule | The Obligatory Interface for Modules]] ** [[Documentation/Modules/Interfaces | Task Specific Interfaces of Modules]] == Various == * [[Documentation/Related | Links and Related Software]] 36 10 2013-02-15T21:19:56Z Dirk 2 /* Developers' Guide */ wikitext text/x-wiki == Download == * [[Download | Executable]] * [[Documentation/Download/SVN | Source Code]] * [[Documentation/Software/Requirements | Software Requirements]] == Theory == * [[Documentation/DoE | Introduction to Design of Experiment]] * [[Documentation/Optimization | Introduction to Automated Optimization]] * [[Documentation/Machine_Learning | Introduction to Machine Learning]] * [[Documentation/Notation | Symbols and Notation]] == Users' Guide == * [[screenshots | A First Introduction to OpenOPAL in the Screenshots]] * [[Documentation/Installation | Download and Installation of OpenOPAL]] * [[Documentation/Modules | Module Documentation of OpenOPAL]] == Developers' Guide == * [[Documentation/Compiling | Developing and Compiling]] * Guidelines for Coding ** [[Documentation/coding/naming | Naming Conventions]] ** [[Documentation/coding/contracts | Contracts]] ** [[Documentation/coding/formatting | Code Formatting]] * Concepts behind OpenOpal ** [[Documentation/Modules/Execution | Module Execution]] ** [[Documentation/Modules/IModule | The Obligatory Interface for Modules]] ** [[Documentation/Modules/Interfaces | Task Specific Interfaces of Modules]] == Various == * [[Documentation/Related | Links and Related Software]] 41 36 2013-02-15T21:26:15Z Dirk 2 /* Users' Guide */ wikitext text/x-wiki == Download == * [[Download | Executable]] * [[Documentation/Download/SVN | Source Code]] * [[Documentation/Software/Requirements | Software Requirements]] == Theory == * [[Documentation/DoE | Introduction to Design of Experiment]] * [[Documentation/Optimization | Introduction to Automated Optimization]] * [[Documentation/Machine_Learning | Introduction to Machine Learning]] * [[Documentation/Notation | Symbols and Notation]] == Users' Guide == * [[screenshots | A First Introduction to OpenOPAL in the Screenshots]] * [[Installation | Installation of OpenOPAL]] * [[Documentation/Modules | Module Documentation of OpenOPAL]] == Developers' Guide == * [[Documentation/Compiling | Developing and Compiling]] * Guidelines for Coding ** [[Documentation/coding/naming | Naming Conventions]] ** [[Documentation/coding/contracts | Contracts]] ** [[Documentation/coding/formatting | Code Formatting]] * Concepts behind OpenOpal ** [[Documentation/Modules/Execution | Module Execution]] ** [[Documentation/Modules/IModule | The Obligatory Interface for Modules]] ** [[Documentation/Modules/Interfaces | Task Specific Interfaces of Modules]] == Various == * [[Documentation/Related | Links and Related Software]] 0 11 11 2013-02-04T14:24:02Z Dirk 2 Created page with "'''Modules''' contain all the functionality for optimizing and learning. One '''Modules''' may contain an optimization algorithm, an artificial neural network, or a problem to op..." wikitext text/x-wiki '''Modules''' contain all the functionality for optimizing and learning. One '''Modules''' may contain an optimization algorithm, an artificial neural network, or a problem to optimize. Here is a list of documented modules in OpenOpal. Further modules may exist, but may not yet be documented. == Single Objective Optimization Algorithms == === Indirect, Deterministic Algorithms === Not implemented, yet. === Direct, Deterministic Algorithms === * [[Documentation/Modules/OptAlgSIMPLEX | <code>OptAlgSIMPLEX</code>: Nelder-Mead Simplex Algorithm]] === Indirect, Stochastic Algorithms === * Evolutionary Algorithms ** [[Documentation/Modules/OptAlgOpO|<code>OptAlgOpO</code>: 1+1 Evolution Strategy with 1/5 Success Rule]] ** [[Documentation/Modules/OptAlgCMA|<code>OptAlgCMA</code>: A Multi-member Evolution Strategy with Covariance Matrix Adaptation]] == Single and Multi-Objective Optimization Algorithms == === Indirect, Stochastic Algorithms === * Evolutionary Algorithms ** [[Documentation/Modules/OptAlgMoCMA | <code>OptAlgMoCMA</code>: Elitist Evolution Strategy with Covariance Matrix Adaptation]] * Particle Methods ** [[Documentation/Modules/OptAlgMOPSO | <code>OptAlgMOPSO</code>: Particle Swarm Optimization Algorithm]] == Design of Experiments == * [[Documentation/Modules/DoePlanner | <code>DoePlanner</code>: A Module Containing Different DoE plans]] * [[Documentation/Modules/RandomSampling | <code>RandomSampling</code>: Uniform Random Sampling]] == Optimization Problems == * [[Documentation/Modules/ProblemSimple | <code>ProblemSimple</code> A Simple Test Problem]] * [[Documentation/Modules/ContinuousTestProblems | <code>ContinuousTestProblems </code>: A Set of Single Objective Test Problem]] * [[Documentation/Modules/ContinuousMOTestProblems | <code>ContinuousMOTestProblems </code>: A Set of Multi-Objective Test Problem]] == Machine Learning == * [[Documentation/Modules/NeuralNetwork | <code>NeuralNetwork</code>: Artificial Neural Network]] == Miscellaneous Modules == * [[Documentation/Modules/SurrogateManager | <code>SurrogateManager</code>: A Framework for Surrogate Managing]] 0 12 12 2013-02-04T14:38:18Z Dirk 2 Created page with "[[Documentation/Modules | « back to module overview]] ==Summary== This optimization module is an implementation of the popular Nelder-Mead Simplex Algorithm (1965) [[#NelMead ..." wikitext text/x-wiki [[Documentation/Modules | « back to module overview]] ==Summary== This optimization module is an implementation of the popular Nelder-Mead Simplex Algorithm (1965) [[#NelMead | (1)]]. The SIMPLEX method is a standard direct, deterministic optimization algorithm, which is implemented in many numerical tools (e.g. as method <code>fminsearch.m</code> in the MATLAB(R) optimization toolbox or in [http://www.gnu.org/software/octave/ GNU Octave]). A good introduction is given by Wright [[#Wright | (2)]]. The algorithm works best for a small number of design variables (1-10, sometimes 1-20). It fails, for example, on the Rosenbrock function, if more than 10 design variables are given. ==Properties== ===General=== {| class="wikitable" style="text-align:left" border="2" cellpadding="5" cellspacing="5" |- ! Algorithm | deterministic |- ! Design Variables | Written for continuous variables. Discrete or mixed variables are NOT possible. |- ! Objectives | single-objective for minimization. No constraint handling. |- ! Constraint handling | no |- ! Boundary handling | no |- ! Initialization | Requires at least one of the following: initial solution, initial search region, or bounds. |- |} ===Connections=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Starting at this module | Module requires exactly one connection of type <code>optimization</code>. |- ! Ending at this module |- |} ===Actions=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Name !! Description |- ! '''Run''' | starts the optimization. |- |} ===Options=== The options are currently described as "pop-up help". ==Module Description== The SIMPLEX algorithm is implemented using the paper of Wright [[#Wright | (2)]]. However, some extensions are made as e.g. the initialization is not given in the references. === Initialization === First, an initial simplex is generated. Here, a [http://en.wikipedia.org/wiki/Simplex simplex] is a body in the N-dimensional design space that has N+1 vertices. The vertices are connected by straight lines. For two (N=2) and three (N=3) design variables, a simplex is a triangle or tetrahedron, respectively. If the optimization problem provides an initial solution, this point is taken as first vertex of the simplex. If not, the initial simplex gets a random position obeying certain rules. We distinguish several cases, depending on the problem properties (<code>initial solution, initial search region, bounds</code>). {| border="1" cellspacing="0" ! colspan="3" | Problem Properties Given? || Action |- | <code>initial solution</code> || <code>initial search region</code> || <code>bounds</code> || |- |Yes || No || No || option <code>Initial Size of the Simplex</code> defines the absolute length of the simplex in each design variable direction. I.e. a simplex is constructed, such that the distance between each vertex and the plane generated by the remaining points has this length. |- |Yes or No || Yes || Yes or No || option <code>Initial Size of the Simplex</code> defines the relative length of the simplex in each design variable direction compared to the size of the initial search region (i.e. difference upper to lower limit). Bounds are ignored. |- |Yes or No || No || Yes || option <code>Initial Size of the Simplex</code> defines the relative length of the simplex in each design variable direction compared to the size of the bounds (i.e. difference upper to lower limit). |} === Optimization === The SIMPLEX method follows a deterministic procedure. Except the initialization, always one new point is generated and evaluated. Thus, parallelization is not implemented. ==Usage== ... todo ==Source Code== ToDo:Link to SVN ==References== <span id="NelMead">1</span> Nelder, J. A. and Mead, R. "A Simplex Method for Function Minimization." Comput. J. 7, 308-313, 1965. <span id="Wright">2</span> M. H. Wright. "Direct search methods: once scorned, now respectable". In D. F. Griffiths and G. A. Watson, editors, Numerical Analysis 1995 (Proceedings of the 1995 Dundee Biennial Conference in Numerical Analysis), pages 191–208. Addison Wesley Longman, 1996. [[Documentation/Modules | « back to module overview]],[[Documentation/Modules | « back to module overview]] 13 12 2013-02-15T20:15:14Z Dirk 2 /* General */ wikitext text/x-wiki [[Documentation/Modules | « back to module overview]] ==Summary== This optimization module is an implementation of the popular Nelder-Mead Simplex Algorithm (1965) [[#NelMead | (1)]]. The SIMPLEX method is a standard direct, deterministic optimization algorithm, which is implemented in many numerical tools (e.g. as method <code>fminsearch.m</code> in the MATLAB(R) optimization toolbox or in [http://www.gnu.org/software/octave/ GNU Octave]). A good introduction is given by Wright [[#Wright | (2)]]. The algorithm works best for a small number of design variables (1-10, sometimes 1-20). It fails, for example, on the Rosenbrock function, if more than 10 design variables are given. ==Properties== ===General=== {| class="wikitable" style="text-align:left" border="2" cellpadding="5" cellspacing="5" |- ! Algorithm | deterministic |- ! Design Variables | Written for continuous variables. Discrete or mixed variables are NOT possible. |- ! Objectives | single-objective for minimization. |- ! Constraint handling | no |- ! Boundary handling | no |- ! Initialization | Requires at least one of the following: initial solution, initial search region, or bounds. |- |} ===Connections=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Starting at this module | Module requires exactly one connection of type <code>optimization</code>. |- ! Ending at this module |- |} ===Actions=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Name !! Description |- ! '''Run''' | starts the optimization. |- |} ===Options=== The options are currently described as "pop-up help". ==Module Description== The SIMPLEX algorithm is implemented using the paper of Wright [[#Wright | (2)]]. However, some extensions are made as e.g. the initialization is not given in the references. === Initialization === First, an initial simplex is generated. Here, a [http://en.wikipedia.org/wiki/Simplex simplex] is a body in the N-dimensional design space that has N+1 vertices. The vertices are connected by straight lines. For two (N=2) and three (N=3) design variables, a simplex is a triangle or tetrahedron, respectively. If the optimization problem provides an initial solution, this point is taken as first vertex of the simplex. If not, the initial simplex gets a random position obeying certain rules. We distinguish several cases, depending on the problem properties (<code>initial solution, initial search region, bounds</code>). {| border="1" cellspacing="0" ! colspan="3" | Problem Properties Given? || Action |- | <code>initial solution</code> || <code>initial search region</code> || <code>bounds</code> || |- |Yes || No || No || option <code>Initial Size of the Simplex</code> defines the absolute length of the simplex in each design variable direction. I.e. a simplex is constructed, such that the distance between each vertex and the plane generated by the remaining points has this length. |- |Yes or No || Yes || Yes or No || option <code>Initial Size of the Simplex</code> defines the relative length of the simplex in each design variable direction compared to the size of the initial search region (i.e. difference upper to lower limit). Bounds are ignored. |- |Yes or No || No || Yes || option <code>Initial Size of the Simplex</code> defines the relative length of the simplex in each design variable direction compared to the size of the bounds (i.e. difference upper to lower limit). |} === Optimization === The SIMPLEX method follows a deterministic procedure. Except the initialization, always one new point is generated and evaluated. Thus, parallelization is not implemented. ==Usage== ... todo ==Source Code== ToDo:Link to SVN ==References== <span id="NelMead">1</span> Nelder, J. A. and Mead, R. "A Simplex Method for Function Minimization." Comput. J. 7, 308-313, 1965. <span id="Wright">2</span> M. H. Wright. "Direct search methods: once scorned, now respectable". In D. F. Griffiths and G. A. Watson, editors, Numerical Analysis 1995 (Proceedings of the 1995 Dundee Biennial Conference in Numerical Analysis), pages 191–208. Addison Wesley Longman, 1996. [[Documentation/Modules | « back to module overview]],[[Documentation/Modules | « back to module overview]] 14 13 2013-02-15T20:16:12Z Dirk 2 /* References */ wikitext text/x-wiki [[Documentation/Modules | « back to module overview]] ==Summary== This optimization module is an implementation of the popular Nelder-Mead Simplex Algorithm (1965) [[#NelMead | (1)]]. The SIMPLEX method is a standard direct, deterministic optimization algorithm, which is implemented in many numerical tools (e.g. as method <code>fminsearch.m</code> in the MATLAB(R) optimization toolbox or in [http://www.gnu.org/software/octave/ GNU Octave]). A good introduction is given by Wright [[#Wright | (2)]]. The algorithm works best for a small number of design variables (1-10, sometimes 1-20). It fails, for example, on the Rosenbrock function, if more than 10 design variables are given. ==Properties== ===General=== {| class="wikitable" style="text-align:left" border="2" cellpadding="5" cellspacing="5" |- ! Algorithm | deterministic |- ! Design Variables | Written for continuous variables. Discrete or mixed variables are NOT possible. |- ! Objectives | single-objective for minimization. |- ! Constraint handling | no |- ! Boundary handling | no |- ! Initialization | Requires at least one of the following: initial solution, initial search region, or bounds. |- |} ===Connections=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Starting at this module | Module requires exactly one connection of type <code>optimization</code>. |- ! Ending at this module |- |} ===Actions=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Name !! Description |- ! '''Run''' | starts the optimization. |- |} ===Options=== The options are currently described as "pop-up help". ==Module Description== The SIMPLEX algorithm is implemented using the paper of Wright [[#Wright | (2)]]. However, some extensions are made as e.g. the initialization is not given in the references. === Initialization === First, an initial simplex is generated. Here, a [http://en.wikipedia.org/wiki/Simplex simplex] is a body in the N-dimensional design space that has N+1 vertices. The vertices are connected by straight lines. For two (N=2) and three (N=3) design variables, a simplex is a triangle or tetrahedron, respectively. If the optimization problem provides an initial solution, this point is taken as first vertex of the simplex. If not, the initial simplex gets a random position obeying certain rules. We distinguish several cases, depending on the problem properties (<code>initial solution, initial search region, bounds</code>). {| border="1" cellspacing="0" ! colspan="3" | Problem Properties Given? || Action |- | <code>initial solution</code> || <code>initial search region</code> || <code>bounds</code> || |- |Yes || No || No || option <code>Initial Size of the Simplex</code> defines the absolute length of the simplex in each design variable direction. I.e. a simplex is constructed, such that the distance between each vertex and the plane generated by the remaining points has this length. |- |Yes or No || Yes || Yes or No || option <code>Initial Size of the Simplex</code> defines the relative length of the simplex in each design variable direction compared to the size of the initial search region (i.e. difference upper to lower limit). Bounds are ignored. |- |Yes or No || No || Yes || option <code>Initial Size of the Simplex</code> defines the relative length of the simplex in each design variable direction compared to the size of the bounds (i.e. difference upper to lower limit). |} === Optimization === The SIMPLEX method follows a deterministic procedure. Except the initialization, always one new point is generated and evaluated. Thus, parallelization is not implemented. ==Usage== ... todo ==Source Code== ToDo:Link to SVN ==References== <span id="NelMead">1</span> Nelder, J. A. and Mead, R. "A Simplex Method for Function Minimization." Comput. J. 7, 308-313, 1965. <span id="Wright">2</span> M. H. Wright. "Direct search methods: once scorned, now respectable". In D. F. Griffiths and G. A. Watson, editors, Numerical Analysis 1995 (Proceedings of the 1995 Dundee Biennial Conference in Numerical Analysis), pages 191–208. Addison Wesley Longman, 1996. [[Documentation/Modules | « back to module overview]] 15 14 2013-02-15T20:16:36Z Dirk 2 wikitext text/x-wiki ==Summary== This optimization module is an implementation of the popular Nelder-Mead Simplex Algorithm (1965) [[#NelMead | (1)]]. The SIMPLEX method is a standard direct, deterministic optimization algorithm, which is implemented in many numerical tools (e.g. as method <code>fminsearch.m</code> in the MATLAB(R) optimization toolbox or in [http://www.gnu.org/software/octave/ GNU Octave]). A good introduction is given by Wright [[#Wright | (2)]]. The algorithm works best for a small number of design variables (1-10, sometimes 1-20). It fails, for example, on the Rosenbrock function, if more than 10 design variables are given. ==Properties== ===General=== {| class="wikitable" style="text-align:left" border="2" cellpadding="5" cellspacing="5" |- ! Algorithm | deterministic |- ! Design Variables | Written for continuous variables. Discrete or mixed variables are NOT possible. |- ! Objectives | single-objective for minimization. |- ! Constraint handling | no |- ! Boundary handling | no |- ! Initialization | Requires at least one of the following: initial solution, initial search region, or bounds. |- |} ===Connections=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Starting at this module | Module requires exactly one connection of type <code>optimization</code>. |- ! Ending at this module |- |} ===Actions=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Name !! Description |- ! '''Run''' | starts the optimization. |- |} ===Options=== The options are currently described as "pop-up help". ==Module Description== The SIMPLEX algorithm is implemented using the paper of Wright [[#Wright | (2)]]. However, some extensions are made as e.g. the initialization is not given in the references. === Initialization === First, an initial simplex is generated. Here, a [http://en.wikipedia.org/wiki/Simplex simplex] is a body in the N-dimensional design space that has N+1 vertices. The vertices are connected by straight lines. For two (N=2) and three (N=3) design variables, a simplex is a triangle or tetrahedron, respectively. If the optimization problem provides an initial solution, this point is taken as first vertex of the simplex. If not, the initial simplex gets a random position obeying certain rules. We distinguish several cases, depending on the problem properties (<code>initial solution, initial search region, bounds</code>). {| border="1" cellspacing="0" ! colspan="3" | Problem Properties Given? || Action |- | <code>initial solution</code> || <code>initial search region</code> || <code>bounds</code> || |- |Yes || No || No || option <code>Initial Size of the Simplex</code> defines the absolute length of the simplex in each design variable direction. I.e. a simplex is constructed, such that the distance between each vertex and the plane generated by the remaining points has this length. |- |Yes or No || Yes || Yes or No || option <code>Initial Size of the Simplex</code> defines the relative length of the simplex in each design variable direction compared to the size of the initial search region (i.e. difference upper to lower limit). Bounds are ignored. |- |Yes or No || No || Yes || option <code>Initial Size of the Simplex</code> defines the relative length of the simplex in each design variable direction compared to the size of the bounds (i.e. difference upper to lower limit). |} === Optimization === The SIMPLEX method follows a deterministic procedure. Except the initialization, always one new point is generated and evaluated. Thus, parallelization is not implemented. ==Usage== ... todo ==Source Code== ToDo:Link to SVN ==References== <span id="NelMead">1</span> Nelder, J. A. and Mead, R. "A Simplex Method for Function Minimization." Comput. J. 7, 308-313, 1965. <span id="Wright">2</span> M. H. Wright. "Direct search methods: once scorned, now respectable". In D. F. Griffiths and G. A. Watson, editors, Numerical Analysis 1995 (Proceedings of the 1995 Dundee Biennial Conference in Numerical Analysis), pages 191–208. Addison Wesley Longman, 1996. 16 15 2013-02-15T20:17:15Z Dirk 2 /* References */ wikitext text/x-wiki ==Summary== This optimization module is an implementation of the popular Nelder-Mead Simplex Algorithm (1965) [[#NelMead | (1)]]. The SIMPLEX method is a standard direct, deterministic optimization algorithm, which is implemented in many numerical tools (e.g. as method <code>fminsearch.m</code> in the MATLAB(R) optimization toolbox or in [http://www.gnu.org/software/octave/ GNU Octave]). A good introduction is given by Wright [[#Wright | (2)]]. The algorithm works best for a small number of design variables (1-10, sometimes 1-20). It fails, for example, on the Rosenbrock function, if more than 10 design variables are given. ==Properties== ===General=== {| class="wikitable" style="text-align:left" border="2" cellpadding="5" cellspacing="5" |- ! Algorithm | deterministic |- ! Design Variables | Written for continuous variables. Discrete or mixed variables are NOT possible. |- ! Objectives | single-objective for minimization. |- ! Constraint handling | no |- ! Boundary handling | no |- ! Initialization | Requires at least one of the following: initial solution, initial search region, or bounds. |- |} ===Connections=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Starting at this module | Module requires exactly one connection of type <code>optimization</code>. |- ! Ending at this module |- |} ===Actions=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Name !! Description |- ! '''Run''' | starts the optimization. |- |} ===Options=== The options are currently described as "pop-up help". ==Module Description== The SIMPLEX algorithm is implemented using the paper of Wright [[#Wright | (2)]]. However, some extensions are made as e.g. the initialization is not given in the references. === Initialization === First, an initial simplex is generated. Here, a [http://en.wikipedia.org/wiki/Simplex simplex] is a body in the N-dimensional design space that has N+1 vertices. The vertices are connected by straight lines. For two (N=2) and three (N=3) design variables, a simplex is a triangle or tetrahedron, respectively. If the optimization problem provides an initial solution, this point is taken as first vertex of the simplex. If not, the initial simplex gets a random position obeying certain rules. We distinguish several cases, depending on the problem properties (<code>initial solution, initial search region, bounds</code>). {| border="1" cellspacing="0" ! colspan="3" | Problem Properties Given? || Action |- | <code>initial solution</code> || <code>initial search region</code> || <code>bounds</code> || |- |Yes || No || No || option <code>Initial Size of the Simplex</code> defines the absolute length of the simplex in each design variable direction. I.e. a simplex is constructed, such that the distance between each vertex and the plane generated by the remaining points has this length. |- |Yes or No || Yes || Yes or No || option <code>Initial Size of the Simplex</code> defines the relative length of the simplex in each design variable direction compared to the size of the initial search region (i.e. difference upper to lower limit). Bounds are ignored. |- |Yes or No || No || Yes || option <code>Initial Size of the Simplex</code> defines the relative length of the simplex in each design variable direction compared to the size of the bounds (i.e. difference upper to lower limit). |} === Optimization === The SIMPLEX method follows a deterministic procedure. Except the initialization, always one new point is generated and evaluated. Thus, parallelization is not implemented. ==Usage== ... todo ==Source Code== ToDo:Link to SVN ==References== <span id="NelMead">1</span> Nelder, J. A. and Mead, R. "A Simplex Method for Function Minimization." Comput. J. 7, 308-313, 1965. <span id="Wright">2</span> M. H. Wright. "Direct search methods: once scorned, now respectable". In D. F. Griffiths and G. A. Watson, editors, Numerical Analysis 1995 (Proceedings of the 1995 Dundee Biennial Conference in Numerical Analysis), pages 191–208. Addison Wesley Longman, 1996. 0 13 17 2013-02-15T20:20:20Z Dirk 2 Created page with "= The CMA-ES = ==Summary== This optimization module is an implementation of the Evolution Strategy with Covariance Matrix Adaptation (CMA-ES). Among the tree evolutionary oper..." wikitext text/x-wiki = The CMA-ES = ==Summary== This optimization module is an implementation of the Evolution Strategy with Covariance Matrix Adaptation (CMA-ES). Among the tree evolutionary operators (Recombination, Mutation, Selection), the mutation is considered the most important. Mutation is performed by sampling a Covariance Matrix. The parameters of the matrix (variances and correlation coefficients) are adapted by tracking the path of successful mutations. ==Properties== ===General=== {| class="wikitable" style="text-align:left" border="2" cellpadding="5" cellspacing="5" |- ! Algorithm | stochastic - generates new solutions by sampling a probability function, however deterministic adaptation of the covariance matrix. |- ! Design Variables | Written for continuous variables. No discrete or mixed variables are possible. |- ! Objectives | single-objective for minimization. |- ! Constraint handling | no |- ! Boundary handling | yes |- ! Initialization | Requires at least one of the following: initial solution, initial search region, or bounds. |- |} ===Connections=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Starting at this module | Module requires exactly one connection of type <code>optimization</code>. |- ! Ending at this module | - |- |} ===Actions=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Name !! Description |- ! '''Run''' | starts the optimization. |- |} ===Options=== The options are currently only described in the references (see below). ==Module Description== === Initialization === The algorithm distinguishes several cases, depending on the problem properties (<code>initial solution, initial search region, bounds</code>). === Optimization === The algorithm contains stochastic processes and operates with a population. Parallelization on the basis of the population size is implemented. ==Usage== ... todo ==Source Code== ToDo:Link to SVN ==References== Detailed information is given at http://www.lri.fr/~hansen/ . 43 17 2013-02-15T21:44:59Z Admin 1 wikitext text/x-wiki ==Summary== This optimization module is an implementation of the Evolution Strategy with Covariance Matrix Adaptation (CMA-ES). Among the tree evolutionary operators (Recombination, Mutation, Selection), the mutation is considered the most important. Mutation is performed by sampling a Covariance Matrix. The parameters of the matrix (variances and correlation coefficients) are adapted by tracking the path of successful mutations. ==Properties== ===General=== {| class="wikitable" style="text-align:left" border="2" cellpadding="5" cellspacing="5" |- ! Algorithm | stochastic - generates new solutions by sampling a probability function, however deterministic adaptation of the covariance matrix. |- ! Design Variables | Written for continuous variables. No discrete or mixed variables are possible. |- ! Objectives | single-objective for minimization. |- ! Constraint handling | no |- ! Boundary handling | yes |- ! Initialization | Requires at least one of the following: initial solution, initial search region, or bounds. |- |} ===Connections=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Starting at this module | Module requires exactly one connection of type <code>optimization</code>. |- ! Ending at this module | - |- |} ===Actions=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Name !! Description |- ! '''Run''' | starts the optimization. |- |} ===Options=== The options are currently only described in the references (see below). ==Module Description== === Initialization === The algorithm distinguishes several cases, depending on the problem properties (<code>initial solution, initial search region, bounds</code>). === Optimization === The algorithm contains stochastic processes and operates with a population. Parallelization on the basis of the population size is implemented. ==Usage== ... todo ==Source Code== ToDo:Link to SVN ==References== Detailed information is given at http://www.lri.fr/~hansen/ . 0 14 18 2013-02-15T20:32:28Z Dirk 2 Created page with " = 1+1 Evolution Strategy = ==Summary== The ''1+1 Evolution Strategy with 1/5 Success Rule'' ('''(1+1)-ES''') is one of the simplest Evolution Strategies and has been p..." wikitext text/x-wiki = 1+1 Evolution Strategy = ==Summary== The ''1+1 Evolution Strategy with 1/5 Success Rule'' ('''(1+1)-ES''') is one of the simplest Evolution Strategies and has been proposed by Rechenberg [[#References | (1)]]. The algorithm has a population of two individuals: one parent '''x'''_p and one child '''x'''_c. The parent generates the child. The objective function value of the child ''f''('''x'''_c) is computed and compared to its parent ''f''('''x'''_p). If the child has a better fitness (lower objective function value), the child becomes the new parent, otherwise the parent stays. This algorithm is designed for continuous design variables and has limited performance for discrete design variables. Furthermore, the algorithm is limited to the minimization of a single (objective) function. ==Properties== ===General=== {| class="wikitable" style="text-align:left" border="2" cellpadding="5" cellspacing="5" |- ! Algorithm | stochastic |- ! Design Variables | | Designed for continuous variables. Limited capabilities for discrete and mixed design variables, preferably the number of discrete values is high (i.e. no binary problems!). Limited performance for highly mis-scaled and/or strongly correlated objective functions. |- ! Objectives | single-objective for minimization. |- ! Constraint handling | no |- ! Boundary handling | no |- ! Initialization | Requires at least one of the following: initial solution, initial search region, or bounds. |- |} ===Connections=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Starting at this module | Module requires exactly one connection of type <code>optimization</code>. |- ! Ending at this module |- |} ===Actions=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Name !! Description |- ! '''Run''' | starts the optimization. |- |} ===Options=== The options are currently described as "pop-up help". ==Introduction== The (1+1)-ES has a population of two individuals, one parent and one child. Two natural inspired operators are considered, which are mutation and selection, by which the strategy iteratively approaches the optimum to a problem. Here we consider the minimization of a function ''f''('''x''') with a vector of design variables '''x'''. '''1. Initialization''' The algorithm starts with a single parent '''x'''_p, whose fitness ''f''('''x'''_p) is computed. '''2. Creating a Child''' A child '''x'''_c is created by mutating the design variables of the parent: '''x'''_c = '''x'''_p + '''z''', where '''z''' is a random vector, with each component ''z''_i taken from a normal distribution (i.e. a Gaussian distribution): ''z''_i ~ ''N''(0,''S''²), with zero mean and standard deviation ''S''. The step size ''S'' controls the strength of the mutation and is adapted while optimizing the problem. '''3. Selecting the Next Parent''' In the selection step, the fitness of the child and parent is compared and the individual with the lower fitness becomes the parent for the next generation and the other individual is deleted. '''4. Step Size Adaptation''' The step size ''S'' controls the strength of the mutation. For the normally distributed mutation, ''S'' describes the radius of a circle around the parent, characterized that on average 62.5% of the children are within this circle. The step size should be adapted in order to take into account the convergence of the algorithm towards the minimum. In the beginning of an optimization, the parent may be far from the optimum and large step sizes are preferred. The step size should then decrease while approaching to the minimum. A relationship between ideal step size ''S'' and the fraction of improved children compared to their parent is given in the 1/5 success rule: :''Be N the number of design variables of the optimization problem, then after every N mutations, check how many successes have occurred over the preceding 10N mutations. If this number is less than 2N, multiply the step size by the factor 0.85; divide the step size by 0.85 if more than 2N successes occurred.'' Please note that one mutation means the creation of one child. '''5. Decision''' Repeat with Point 2, if no termination criterion is violated. ==Usage== ... todo ==Source Code== ToDo:Link to SVN ==References== 1. Rechenberg, I.: Evolutionsstrategie, Friedrich Frommann Verlag, 1973 42 18 2013-02-15T21:44:23Z Admin 1 wikitext text/x-wiki ==Summary== The ''1+1 Evolution Strategy with 1/5 Success Rule'' ('''(1+1)-ES''') is one of the simplest Evolution Strategies and has been proposed by Rechenberg [[#References | (1)]]. The algorithm has a population of two individuals: one parent '''x'''_p and one child '''x'''_c. The parent generates the child. The objective function value of the child ''f''('''x'''_c) is computed and compared to its parent ''f''('''x'''_p). If the child has a better fitness (lower objective function value), the child becomes the new parent, otherwise the parent stays. This algorithm is designed for continuous design variables and has limited performance for discrete design variables. Furthermore, the algorithm is limited to the minimization of a single (objective) function. ==Properties== ===General=== {| class="wikitable" style="text-align:left" border="2" cellpadding="5" cellspacing="5" |- ! Algorithm | stochastic |- ! Design Variables | | Designed for continuous variables. Limited capabilities for discrete and mixed design variables, preferably the number of discrete values is high (i.e. no binary problems!). Limited performance for highly mis-scaled and/or strongly correlated objective functions. |- ! Objectives | single-objective for minimization. |- ! Constraint handling | no |- ! Boundary handling | no |- ! Initialization | Requires at least one of the following: initial solution, initial search region, or bounds. |- |} ===Connections=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Starting at this module | Module requires exactly one connection of type <code>optimization</code>. |- ! Ending at this module |- |} ===Actions=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Name !! Description |- ! '''Run''' | starts the optimization. |- |} ===Options=== The options are currently described as "pop-up help". ==Introduction== The (1+1)-ES has a population of two individuals, one parent and one child. Two natural inspired operators are considered, which are mutation and selection, by which the strategy iteratively approaches the optimum to a problem. Here we consider the minimization of a function ''f''('''x''') with a vector of design variables '''x'''. '''1. Initialization''' The algorithm starts with a single parent '''x'''_p, whose fitness ''f''('''x'''_p) is computed. '''2. Creating a Child''' A child '''x'''_c is created by mutating the design variables of the parent: '''x'''_c = '''x'''_p + '''z''', where '''z''' is a random vector, with each component ''z''_i taken from a normal distribution (i.e. a Gaussian distribution): ''z''_i ~ ''N''(0,''S''²), with zero mean and standard deviation ''S''. The step size ''S'' controls the strength of the mutation and is adapted while optimizing the problem. '''3. Selecting the Next Parent''' In the selection step, the fitness of the child and parent is compared and the individual with the lower fitness becomes the parent for the next generation and the other individual is deleted. '''4. Step Size Adaptation''' The step size ''S'' controls the strength of the mutation. For the normally distributed mutation, ''S'' describes the radius of a circle around the parent, characterized that on average 62.5% of the children are within this circle. The step size should be adapted in order to take into account the convergence of the algorithm towards the minimum. In the beginning of an optimization, the parent may be far from the optimum and large step sizes are preferred. The step size should then decrease while approaching to the minimum. A relationship between ideal step size ''S'' and the fraction of improved children compared to their parent is given in the 1/5 success rule: :''Be N the number of design variables of the optimization problem, then after every N mutations, check how many successes have occurred over the preceding 10N mutations. If this number is less than 2N, multiply the step size by the factor 0.85; divide the step size by 0.85 if more than 2N successes occurred.'' Please note that one mutation means the creation of one child. '''5. Decision''' Repeat with Point 2, if no termination criterion is violated. ==Usage== ... todo ==Source Code== ToDo:Link to SVN ==References== 1. Rechenberg, I.: Evolutionsstrategie, Friedrich Frommann Verlag, 1973 0 15 19 2013-02-15T20:35:26Z Dirk 2 Created page with "= The Elitist Evolution Strategy with Covariance Matrix Adaptation = ==Summary== This optimization module is an implementation of the elitist Evolution Strategy with Covarianc..." wikitext text/x-wiki = The Elitist Evolution Strategy with Covariance Matrix Adaptation = ==Summary== This optimization module is an implementation of the elitist Evolution Strategy with Covariance Matrix Adaptation (CMA-ES) for single- and multi-objective optimization [[#References | (1)]], however it contains some modifications to the publication. The algorithm uses one or multiple parents. Each parent generates one or multiple children. The algorithm is elitist: Always the best individuals among all parents and children are selected as parents of the next generation. This algorithm is designed for continuous variables and can not handle discrete problems. Furthermore, the algorithm is implemented for minimizing a single and multiple objective function(s). ==Properties== ===General=== {| class="wikitable" style="text-align:left" border="2" cellpadding="5" cellspacing="5" |- ! Algorithm | stochastic - deterministic adaptation of the covariance matrix. |- ! Design Variables | Written for continuous variables. No discrete or mixed variables are possible. |- ! Objectives | single- and multi-objective for minimization. |- ! Constraint handling | no |- ! Boundary handling | no |- ! Initialization | Requires at least one of the following: initial solution, initial search region, or bounds. |- |} ===Connections=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Starting at his module | Module requires exactly one connection of type <code>optimization</code>. |- ! Ending at this module | - |- |} ===Actions=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Name !! Description |- ! '''Run''' | starts the optimization. |- |} ===Options=== The options are currently described in the pop-up help. ==Module Description== === Initialization === The initial parents are randomly generated within the <code>initial search region</code> (if existing) or otherwise between the <code>bounds</code>. === Optimization === The algorithm contains stochastic processes and operates with a population. Parallelization on the basis of the population size is implemented. The (<code>mu+lambda</code>)-ES has a population of <code>mu</code> parents and <code>lambda</code> children. The population size depends on the number of objectives and the following values are recommended: # <code>mu=1</code> and <code>lambda >= 1</code> for ''single objective optimization''. # <code>mu=50</code> and <code>lambda = 1</code> , for ''multi-objective optimization'' (here it is recommended that each parent has only one child). While evolutionary algorithms typically use the 3 natural inspired operators mutation, recombination and selection, this algorithms uses mutation and selection only. The selection is elitist: Among all parents and children, the best <code>mu</code> individuals are selected as parents of the next generation. The mutation is based on a multivariate normal distribution and the mutation distribution is adapted by a deterministic rule: A child '''x'''_c is created by mutating the design variables of the parent: '''x'''_c = '''x'''_p + '''z''', where '''z''' is a random vector, taken from a normal distribution (i.e. a Gaussian distribution): '''z''' ~ S * ''N''(0,'''C'''), with zero mean and covariance matrix '''C'''. The step size ''S'' controls the strength and the covariance matrix '''C''' the correlation of the mutation. The step size ''S'' and the covariance matrix '''C''' is adapted by a deterministic rule in order to take into account the convergence of the algorithm towards the minimum. In the beginning of an optimization, the parent may be far from the optimum and large step sizes are preferred. The step size should then decrease while approaching to the minimum. ==Usage== ... todo ==Source Code== ToDo:Link to SVN ==References== (1) Igel, C., N. Hansen and S. Roth (2007). Covariance Matrix Adaptation for Multi-objective Optimization. Evolutionary Computation, 15(1), pp.1-28 (2) http://www.lri.fr/~hansen 44 19 2013-02-15T21:45:26Z Admin 1 wikitext text/x-wiki ==Summary== This optimization module is an implementation of the elitist Evolution Strategy with Covariance Matrix Adaptation (CMA-ES) for single- and multi-objective optimization [[#References | (1)]], however it contains some modifications to the publication. The algorithm uses one or multiple parents. Each parent generates one or multiple children. The algorithm is elitist: Always the best individuals among all parents and children are selected as parents of the next generation. This algorithm is designed for continuous variables and can not handle discrete problems. Furthermore, the algorithm is implemented for minimizing a single and multiple objective function(s). ==Properties== ===General=== {| class="wikitable" style="text-align:left" border="2" cellpadding="5" cellspacing="5" |- ! Algorithm | stochastic - deterministic adaptation of the covariance matrix. |- ! Design Variables | Written for continuous variables. No discrete or mixed variables are possible. |- ! Objectives | single- and multi-objective for minimization. |- ! Constraint handling | no |- ! Boundary handling | no |- ! Initialization | Requires at least one of the following: initial solution, initial search region, or bounds. |- |} ===Connections=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Starting at his module | Module requires exactly one connection of type <code>optimization</code>. |- ! Ending at this module | - |- |} ===Actions=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Name !! Description |- ! '''Run''' | starts the optimization. |- |} ===Options=== The options are currently described in the pop-up help. ==Module Description== === Initialization === The initial parents are randomly generated within the <code>initial search region</code> (if existing) or otherwise between the <code>bounds</code>. === Optimization === The algorithm contains stochastic processes and operates with a population. Parallelization on the basis of the population size is implemented. The (<code>mu+lambda</code>)-ES has a population of <code>mu</code> parents and <code>lambda</code> children. The population size depends on the number of objectives and the following values are recommended: # <code>mu=1</code> and <code>lambda >= 1</code> for ''single objective optimization''. # <code>mu=50</code> and <code>lambda = 1</code> , for ''multi-objective optimization'' (here it is recommended that each parent has only one child). While evolutionary algorithms typically use the 3 natural inspired operators mutation, recombination and selection, this algorithms uses mutation and selection only. The selection is elitist: Among all parents and children, the best <code>mu</code> individuals are selected as parents of the next generation. The mutation is based on a multivariate normal distribution and the mutation distribution is adapted by a deterministic rule: A child '''x'''_c is created by mutating the design variables of the parent: '''x'''_c = '''x'''_p + '''z''', where '''z''' is a random vector, taken from a normal distribution (i.e. a Gaussian distribution): '''z''' ~ S * ''N''(0,'''C'''), with zero mean and covariance matrix '''C'''. The step size ''S'' controls the strength and the covariance matrix '''C''' the correlation of the mutation. The step size ''S'' and the covariance matrix '''C''' is adapted by a deterministic rule in order to take into account the convergence of the algorithm towards the minimum. In the beginning of an optimization, the parent may be far from the optimum and large step sizes are preferred. The step size should then decrease while approaching to the minimum. ==Usage== ... todo ==Source Code== ToDo:Link to SVN ==References== (1) Igel, C., N. Hansen and S. Roth (2007). Covariance Matrix Adaptation for Multi-objective Optimization. Evolutionary Computation, 15(1), pp.1-28 (2) http://www.lri.fr/~hansen 0 16 20 2013-02-15T20:36:42Z Dirk 2 Created page with "= The Multi-Objective Particle Swarm Optimizer = ==Summary== This optimization module is an implementation of the particle swarm optimization algorithm for single- and multi-ob..." wikitext text/x-wiki = The Multi-Objective Particle Swarm Optimizer = ==Summary== This optimization module is an implementation of the particle swarm optimization algorithm for single- and multi-objective optimization [[#References | (1)]], however it contains some modifications to the publication. The algorithm reflects the natural movement of flocking birds. The algorithm is elitist: Always the best particles are kept as guides. This algorithm is designed for continuous variables and can not handle discrete problems. Furthermore, the algorithm is implemented for minimizing a single and multiple objective function(s). ==Properties== ===General=== {| class="wikitable" style="text-align:left" border="2" cellpadding="5" cellspacing="5" |- ! Algorithm | stochastic - stochastic adaptation of the velocities. |- ! Design Variables | Written for continuous variables. No discrete or mixed variables are possible. |- ! Objectives | single- and multi-objective for minimization. |- ! Constraint handling | no |- ! Boundary handling | no |- ! Initialization | Requires at least one of the following: initial search region or bounds. |- |} ===Connections=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Starting at this module | Module requires exactly one connection of type <code>optimization</code>. |- ! Ending at this module | - |- |} ===Actions=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Name !! Description |- ! '''Run''' | starts the optimization. |- |} ===Options=== The options are currently described in the pop-up help. ==Module Description== === Initialization === The initial particles are randomly generated within the <code>initial search region</code> (if existing) or otherwise between the <code>bounds</code>. === Optimization === The algorithm contains stochastic processes and operates with a set of particles. Parallelization on the basis of the number of particles is implemented. ==Usage== ... todo ==Source Code== ToDo:Link to SVN ==References== (1) Sanaz Mostaghim. Multi-Objective Evolutionary Algorithms. Data Structures, Convergence, and Diversity. Paderborn, Germany, November 2004. 45 20 2013-02-15T21:46:18Z Admin 1 wikitext text/x-wiki ==Summary== This optimization module is an implementation of the particle swarm optimization algorithm for single- and multi-objective optimization [[#References | (1)]], however it contains some modifications to the publication. The algorithm reflects the natural movement of flocking birds. The algorithm is elitist: Always the best particles are kept as guides. This algorithm is designed for continuous variables and can not handle discrete problems. Furthermore, the algorithm is implemented for minimizing a single and multiple objective function(s). ==Properties== ===General=== {| class="wikitable" style="text-align:left" border="2" cellpadding="5" cellspacing="5" |- ! Algorithm | stochastic - stochastic adaptation of the velocities. |- ! Design Variables | Written for continuous variables. No discrete or mixed variables are possible. |- ! Objectives | single- and multi-objective for minimization. |- ! Constraint handling | no |- ! Boundary handling | no |- ! Initialization | Requires at least one of the following: initial search region or bounds. |- |} ===Connections=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Starting at this module | Module requires exactly one connection of type <code>optimization</code>. |- ! Ending at this module | - |- |} ===Actions=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Name !! Description |- ! '''Run''' | starts the optimization. |- |} ===Options=== The options are currently described in the pop-up help. ==Module Description== === Initialization === The initial particles are randomly generated within the <code>initial search region</code> (if existing) or otherwise between the <code>bounds</code>. === Optimization === The algorithm contains stochastic processes and operates with a set of particles. Parallelization on the basis of the number of particles is implemented. ==Usage== ... todo ==Source Code== ToDo:Link to SVN ==References== (1) Sanaz Mostaghim. Multi-Objective Evolutionary Algorithms. Data Structures, Convergence, and Diversity. Paderborn, Germany, November 2004. 0 17 21 2013-02-15T20:37:42Z Dirk 2 Created page with "= DoEPlanner - The Design Of Experiment Module = ==Summary== This module contains general implementation for Design of Experiment (DoE) plans. Currently, the Full Factorial an..." wikitext text/x-wiki = DoEPlanner - The Design Of Experiment Module = ==Summary== This module contains general implementation for Design of Experiment (DoE) plans. Currently, the Full Factorial and Latin Hypercube plan are implemented. For an introduction to DoE, see the [[Documentation/DoE | Introduction to Design of Experiment]]. ==Properties== ===General=== {| class="wikitable" style="text-align:left" border="2" cellpadding="5" cellspacing="5" |- ! Algorithm | stochastic or deterministic. |- ! Design Variables | continuous, discrete or mixed variables are possible. |- ! Objectives | not required, thus any number of objectives can be handled. |- ! Constraint handling | not required, thus any number of constraints can be handled. |- ! Boundary handling | not required. |- ! Initialization | Does not required initial solution, initial search region, or bounds. |- |} ===Connections=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Starting at this module | Module requires exactly one connection of type <code>optimization</code>. |- ! Ending at this module | - |- |} ===Actions=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Name !! Description |- ! '''Run''' | starts the DoE. |- |} ===Options=== The options are currently only described in the references (see below) and as pop-up help. ==Module Description== === Initialization === Not required. === Algorithm === The algorithm may contain stochastic processes. Parallel evaluation of experiments is possible. ==Usage== ... todo ==Source Code== ToDo:Link to SVN ==References== Detailed information is given at [[Documentation/DoE]]. 46 21 2013-02-15T21:46:43Z Admin 1 /* DoEPlanner - The Design Of Experiment Module */ wikitext text/x-wiki ==Summary== This module contains general implementation for Design of Experiment (DoE) plans. Currently, the Full Factorial and Latin Hypercube plan are implemented. For an introduction to DoE, see the [[Documentation/DoE | Introduction to Design of Experiment]]. ==Properties== ===General=== {| class="wikitable" style="text-align:left" border="2" cellpadding="5" cellspacing="5" |- ! Algorithm | stochastic or deterministic. |- ! Design Variables | continuous, discrete or mixed variables are possible. |- ! Objectives | not required, thus any number of objectives can be handled. |- ! Constraint handling | not required, thus any number of constraints can be handled. |- ! Boundary handling | not required. |- ! Initialization | Does not required initial solution, initial search region, or bounds. |- |} ===Connections=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Starting at this module | Module requires exactly one connection of type <code>optimization</code>. |- ! Ending at this module | - |- |} ===Actions=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Name !! Description |- ! '''Run''' | starts the DoE. |- |} ===Options=== The options are currently only described in the references (see below) and as pop-up help. ==Module Description== === Initialization === Not required. === Algorithm === The algorithm may contain stochastic processes. Parallel evaluation of experiments is possible. ==Usage== ... todo ==Source Code== ToDo:Link to SVN ==References== Detailed information is given at [[Documentation/DoE]]. 0 18 22 2013-02-15T20:38:34Z Dirk 2 Created page with "= Random Sampling = ==Summary== This module contains a simple method for Design of Experiments: It just samples random points with a uniform distribution within the bounds. =..." wikitext text/x-wiki = Random Sampling = ==Summary== This module contains a simple method for Design of Experiments: It just samples random points with a uniform distribution within the bounds. ==Properties== ===General=== {| class="wikitable" style="text-align:left" border="2" cellpadding="5" cellspacing="5" |- ! Algorithm | stochastic |- ! Design Variables | continuous, discrete or mixed variables are possible |- ! Objectives | not required, thus any number of objectives can be handled. |- ! Constraint handling | not required, thus any number of constraints can be handled. |- ! Boundary handling | stays within given bounds. |- ! Initialization | Requires bounds. |- |} ===Connections=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Starting at this module | Module requires exactly one connection of type <code>optimization</code>. |- ! Ending at this module | - |- |} ===Actions=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Name !! Description |- ! '''Run''' | starts the DoE. |- |} ===Options=== The options are currently only described in the references (see below) and as pop-up help. ==Module Description== === Initialization === Not required. === Algorithm === The algorithm contains stochastic processes. Parallel evaluation of experiments is possible. ==Usage== ... todo ==Source Code== ToDo:Link to SVN ==References== General information is given at [[Documentation/DoE | Introduction to Design of Experiment]]. 47 22 2013-02-15T21:47:08Z Admin 1 /* Random Sampling */ wikitext text/x-wiki ==Summary== This module contains a simple method for Design of Experiments: It just samples random points with a uniform distribution within the bounds. ==Properties== ===General=== {| class="wikitable" style="text-align:left" border="2" cellpadding="5" cellspacing="5" |- ! Algorithm | stochastic |- ! Design Variables | continuous, discrete or mixed variables are possible |- ! Objectives | not required, thus any number of objectives can be handled. |- ! Constraint handling | not required, thus any number of constraints can be handled. |- ! Boundary handling | stays within given bounds. |- ! Initialization | Requires bounds. |- |} ===Connections=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Starting at this module | Module requires exactly one connection of type <code>optimization</code>. |- ! Ending at this module | - |- |} ===Actions=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Name !! Description |- ! '''Run''' | starts the DoE. |- |} ===Options=== The options are currently only described in the references (see below) and as pop-up help. ==Module Description== === Initialization === Not required. === Algorithm === The algorithm contains stochastic processes. Parallel evaluation of experiments is possible. ==Usage== ... todo ==Source Code== ToDo:Link to SVN ==References== General information is given at [[Documentation/DoE | Introduction to Design of Experiment]]. 0 19 23 2013-02-15T20:41:40Z Dirk 2 Created page with "= ProblemSimple - A Simple Optimization Problem = ==Summary== The module <code>ProblemSimple</code> contains a very simple optimization problem, which can be used to illustrate..." wikitext text/x-wiki = ProblemSimple - A Simple Optimization Problem = ==Summary== The module <code>ProblemSimple</code> contains a very simple optimization problem, which can be used to illustrate the optimization process. It contains a time delay, which allows to reduce the speed of evaluations. This can be used e.g. to show the convergence of an optimization algorithm in a presentation. ==Properties== ===General=== {| class="wikitable" style="text-align:left" border="2" cellpadding="5" cellspacing="5" |- ! Algorithm | deterministic test function. |- ! Design Variables | Continuous, discrete, or mixed variables. |- ! Objectives | single-objective for minimization. |- ! Constraints | none |- ! Boundaries | set to fixed value. |- ! Initial Search Region | not set. |- ! Typical X | not set. |- ! Initialization | sets problem properties. |- |} ===Connections=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Starting at his module | - |- ! Ending at this module | Connections of type <code>optimization</code> |- |} ===Actions=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Name !! Description |- ! - | - |- |} ===Options=== The options are the number of discrete and continuous variables and an optional time delay for per evaluation. ==Module Description== === Computation of the Objective === The single objective function ''f'' is a quadratic function. More precisely, ''f'' is computed as the square of all continuous and discrete variables. ''f''('''x''') = sum_i(x_i²) This function is also referred to as the ''sphere function''. ==Usage== - ==Source Code== ToDo:Link to SVN ==References== - 48 23 2013-02-15T21:47:42Z Admin 1 wikitext text/x-wiki ==Summary== The module <code>ProblemSimple</code> contains a very simple optimization problem, which can be used to illustrate the optimization process. It contains a time delay, which allows to reduce the speed of evaluations. This can be used e.g. to show the convergence of an optimization algorithm in a presentation. ==Properties== ===General=== {| class="wikitable" style="text-align:left" border="2" cellpadding="5" cellspacing="5" |- ! Algorithm | deterministic test function. |- ! Design Variables | Continuous, discrete, or mixed variables. |- ! Objectives | single-objective for minimization. |- ! Constraints | none |- ! Boundaries | set to fixed value. |- ! Initial Search Region | not set. |- ! Typical X | not set. |- ! Initialization | sets problem properties. |- |} ===Connections=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Starting at his module | - |- ! Ending at this module | Connections of type <code>optimization</code> |- |} ===Actions=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Name !! Description |- ! - | - |- |} ===Options=== The options are the number of discrete and continuous variables and an optional time delay for per evaluation. ==Module Description== === Computation of the Objective === The single objective function ''f'' is a quadratic function. More precisely, ''f'' is computed as the square of all continuous and discrete variables. ''f''('''x''') = sum_i(x_i²) This function is also referred to as the ''sphere function''. ==Usage== - ==Source Code== ToDo:Link to SVN ==References== - 0 20 24 2013-02-15T20:44:04Z Dirk 2 Created page with "=Design of Experiments= == Introduction == Design of Experiments ('''DoE''') defines methods of how to plan and arrange experiments. We explain the method using the example of a..." wikitext text/x-wiki =Design of Experiments= == Introduction == Design of Experiments ('''DoE''') defines methods of how to plan and arrange experiments. We explain the method using the example of a baker in a bakery. The baker wants to analyze the effect of different settings of his oven to the quality of the resulting bread by conducting several experiments. === Target Values === We define the targets of experiments (here to improve the quality of the bread) as '''target values'''. === Input Parameters === All sources of influence on the target values are referred to as '''factors'''. Three different groups of factors are distinguished: # ''noise factors'': These factors cannot be controlled or controlling these factors is too expensive. As an example, the temperature and humidity in the bakery depends on the season and weather and cannot be controlled. # ''control factors'': These factors can be controlled. However, their influence on the target value is not of interest and thus, these factors are set constant. For example, the baker wants to leave his recipe for the bread unchanged. # ''signal factors'': These factors can be controlled. Their influence is of interest and their values are modified in the experiments. DoE is important when we have to analyze a process with multiple signal factors, in order to determine their effect on the target value(s). '''''Note:''' In the following, we will only consider signal factors. For simplicity, they are referred to as factors.'' === Factor Levels === For each factor, we may want to analyze different values. For example, we want to analyze an oven temperature of 185, 190, 195, and 200^oC and a baking time of 45, 50, 55 and 60 minutes. These different values are referred to as ''factor levels''. === Experiment === One experiment is one combination of different factor levels and the corresponding target values for the experiment. For example, one experiment may be a temperature of 190^oC and a baking time of 60 min. One experiment is also referred to as one '''factor level combination'''. === DoE Plan === The DoE plan defines which experiments are to be conducted and in which sequence they are conducted. The sequence may be important as environmental conditions like temperature may effect the target values as well as hysteresis effects. DoE plans differ in number of total experiments and the order of the experiments. The number of experiments strongly influences the information gain and the trust in the experiments. As references for DoE plans we recommend [ [[#klepp | 1]], [[#wikidoe | 2]] ]. == DoE Plans == A DoE plan can be considered as a set of rules describing how to choose factors, the number of factor levels, factor level values or value distributions, etc.. In the following, two different DoE plans are outlined. === Full Factorial === [[Image:DoEFullFactorial.png|frame|right|A two factor Full Factorial plan. Each square represents one possible experiment. The "X" denote the actual experiments that will be scheduled.]] For given numbers of factor levels for each variable, a limited number of different experiments can be conducted. A DoE plan with all possible experiments is referred to as '''Full Factorial''' plan: The number of factor levels may vary for the factors. All other plans use only a subset of all possible experiments. === Latin Hypercube === [[Image:DoELatinHypercube.png|frame|right|A two factor Latin Hypercube plan. Each square represents one possible experiment. The "X" denote the actual experiments that will be scheduled.]] Compared to the Full Factorial plan, the Latin Hypercube (LHC) sampling dramatically reduces the number of experiments (see e.g. [ [[#wikilhc | 3]] ]). So it is most useful for expensive experiments, whether they be money or time intensive. Latin Hypercube requires the same number of factor levels for all factors. The number of experiments of a LHC plan is equal to the number of factor levels and is independent on the number of factors. This makes it very scalable (O(1)) in respect of number of factors. The philosophy of LHC is to use every factor level exactly once. The figure on the right demonstrates a possible plan for 4 factor levels. As each factor level is only used once, each row and column in the figure must contain exactly one cross. Thus, LHC guaranties that for each factor, the entire range of factor levels is used. == Common Settings for all DoE Plans == The following list explains common settings for all DoE plans. === Number of Iterations === The testing of a set of experiments that a DoE plan proposes is referred to as one ''iteration''. If we would schedule three ''iterations'', each experiment (i.e. a certain factor level combination) in the set is tested exactly three times. Using more than one iteration is only necessary if the system to analyze is noisy (i.e. the target values are noisy), may contain a drift while testing, or produces hysteresis. === Random Scheduling === [[Image:DoERandomBlock.png|thumb|250px|right|Four different scheduling plans of six experiments resulting from DoE plan with three experiments and two iterations. The small double-bordered boxes outline the blocks.]] Without ''random scheduling'', the experiments are tested in a fixed order. With ''randomization'' activated, a random sequence for the experiment is set up. To what extend the randomization occurs depends on whether ''block building'' is active or not. ''Random scheduling'' may help to analyze effects like hysteresis, i.e. the previous experiment effects the outcome of the current experiment. If we run multiple iterations, the effect of hysteresis decreases because of statistical reasons. === Block Building === If ''block building'' is activated, all experiments of one iteration are tested. Then, all experiments of the next iteration are tested. If ''block building'' is '''de'''activated, experiments of different iterations may follow each other. ''Block building'', like ''random scheduling'', may reduce the effect that may occur because of the order in which the experiments get scheduled. While ''random scheduling'' may reduce the effect of subsequent experiments, activating ''block building'' may reduce the effect caused by external (long term) influences. These influences can be quality of the used materials, which may vary over time or depend on the supplier, human interaction with the machines or the accuracy of machines of the same type used for the experiments. == DoE in OpenOpal == A description for DoE in OpenOpal can be found in the module documentation (see [[Documentation/Modules/DoePlanner]]). == References == <span id="klepp">1</span> Wilhelm Kleppmann, Taschenbuch Versuchsplanung (4. Auflage) - Produkte und Prozesse optimieren, Carl Hanser Verlag Muenchen Wien, 2006 <span id="wikidoe">2</span> http://en.wikipedia.org/wiki/Design_of_experiments <span id="wikilhc">3</span> http://en.wikipedia.org/wiki/Latin_hypercube 6 21 25 2013-02-15T20:44:41Z Dirk 2 wikitext text/x-wiki 6 22 26 2013-02-15T20:45:14Z Dirk 2 wikitext text/x-wiki 27 26 2013-02-15T20:48:27Z Dirk 2 uploaded a new version of &quot;[[File:DoELatinHypercube.png]]&quot; wikitext text/x-wiki 6 24 29 2013-02-15T20:52:44Z Dirk 2 wikitext text/x-wiki 0 25 30 2013-02-15T20:55:25Z Dirk 2 Created page with "=Optimization= == Introduction == Optimization searches for the best solution '''x'''* to a problem and can be defined as '''x'''* = argmin (''f''('''x''')) where ''f'' ..." wikitext text/x-wiki =Optimization= == Introduction == Optimization searches for the best solution '''x'''* to a problem and can be defined as '''x'''* = argmin (''f''('''x''')) where ''f'' is the function to be optimized (the objective function) and '''x''' are the design variables for which optimal settings have to be found. This definition can be extended to multiple objectives '''f''' and by constraints. == Some Important Expressions == === Manual vs. Automated Optimization === Optimization is an everyday task. For example, searching the fastest way to work or home is an optimization problem. We speak about ''automated'' optimization, if a computer algorithm solves the problem in an automated fashion, i.e. without user interaction. === The Objective Function === Optimization typically searches for the optimal solution to a problem. For automated optimization, the problem must be encoded in a mathematical function ''f'', which has to be either minimized or maximized. In OpenOpal, only minimization is considered as maximization can be expressed as: max(f) = - min(-f) === Design Variables === The optimal solution is searched by modifying the design variables '''x'''. The objective function depends on the design variables: f = f('''x'''). === Multiple Objectives === If multiple objectives '''f''' should be optimized, then a multi-objective optimization problem has to be solved. Some optimization algorithms search concurrently for multiple compromise solutions for the objectives (Pareto optimization) or a single compromise solution, defined as a weighed sum of all objectives. === Constraints === While the optimization algorithm tries to minimize all objectives, constraints simply have to be fulfilled. For example, the maximal stress in a truss should not exceed a certain limit. If the stress is below the limit, no advantage is gained. If the stress is above the limit, the solution is typically constrained by a penalty value, which increases with increasing constraint violation. === Direct vs. Indirect Search === In OpenOpal, we implement optimization algorithms that search a problem in an iterative fashion, i.e. by computing several different solutions to the problem. The best solution is returned. This iterative search can be either direct or indirect: '''Direct''' search uses only direct information (i.e. the objective and constraint value(s). '''Indirect''' algorithms use indirect information (i.e. gradient and/or higher order derivative information of the objective(s) and constraint(s)). === Stochastic vs. Deterministic Algorithms === While '''stochastic''' algorithms such as Evolutionary Algorithms and Particle Swarm use random values in their search method, '''deterministic''' algorithms like the Simplex Method or gradient based search do not. 31 30 2013-02-15T20:55:51Z Dirk 2 /* The Objective Function */ wikitext text/x-wiki =Optimization= == Introduction == Optimization searches for the best solution '''x'''* to a problem and can be defined as '''x'''* = argmin (''f''('''x''')) where ''f'' is the function to be optimized (the objective function) and '''x''' are the design variables for which optimal settings have to be found. This definition can be extended to multiple objectives '''f''' and by constraints. == Some Important Expressions == === Manual vs. Automated Optimization === Optimization is an everyday task. For example, searching the fastest way to work or home is an optimization problem. We speak about ''automated'' optimization, if a computer algorithm solves the problem in an automated fashion, i.e. without user interaction. === Objective Function === Optimization typically searches for the optimal solution to a problem. For automated optimization, the problem must be encoded in a mathematical function ''f'', which has to be either minimized or maximized. In OpenOpal, only minimization is considered as maximization can be expressed as: max(f) = - min(-f) === Design Variables === The optimal solution is searched by modifying the design variables '''x'''. The objective function depends on the design variables: f = f('''x'''). === Multiple Objectives === If multiple objectives '''f''' should be optimized, then a multi-objective optimization problem has to be solved. Some optimization algorithms search concurrently for multiple compromise solutions for the objectives (Pareto optimization) or a single compromise solution, defined as a weighed sum of all objectives. === Constraints === While the optimization algorithm tries to minimize all objectives, constraints simply have to be fulfilled. For example, the maximal stress in a truss should not exceed a certain limit. If the stress is below the limit, no advantage is gained. If the stress is above the limit, the solution is typically constrained by a penalty value, which increases with increasing constraint violation. === Direct vs. Indirect Search === In OpenOpal, we implement optimization algorithms that search a problem in an iterative fashion, i.e. by computing several different solutions to the problem. The best solution is returned. This iterative search can be either direct or indirect: '''Direct''' search uses only direct information (i.e. the objective and constraint value(s). '''Indirect''' algorithms use indirect information (i.e. gradient and/or higher order derivative information of the objective(s) and constraint(s)). === Stochastic vs. Deterministic Algorithms === While '''stochastic''' algorithms such as Evolutionary Algorithms and Particle Swarm use random values in their search method, '''deterministic''' algorithms like the Simplex Method or gradient based search do not. 0 26 32 2013-02-15T20:59:59Z Dirk 2 Created page with "= Notation = As a math parser is currently not used, we write the math equations as formated text: * Scalars are written as small italic letters, e.g. ''f'' * Vectors are writte..." wikitext text/x-wiki = Notation = As a math parser is currently not used, we write the math equations as formated text: * Scalars are written as small italic letters, e.g. ''f'' * Vectors are written as small bold letters, e.g. '''x'''. * Matrices are written in capital bold letters, e.g. '''C'''. === Symbols === :{| cellpadding="5" width="95%" |- | ''f'', '''f''' | objective function(s) |- | ''x'', '''x''' | design variable(s) |- | ''g'', '''g''' | constraint(s) |- |} === Terminology === :{| cellpadding="5" width="95%" |- | ''solution'' | The term solution is used in optimization. One solution ('''x''','''f''','''g''') consists of a vector of design variables '''x''', the evaluated objective(s) '''f'''('''x''') and constraint(s) '''g'''('''x''')'''. |- |} 33 32 2013-02-15T21:00:44Z Dirk 2 wikitext text/x-wiki == Notation == As a math parser is currently not used, we write the math equations as formated text: * Scalars are written as small italic letters, e.g. ''f'' * Vectors are written as small bold letters, e.g. '''x'''. * Matrices are written in capital bold letters, e.g. '''C'''. == Symbols == :{| cellpadding="5" width="95%" |- | ''f'', '''f''' | objective function(s) |- | ''x'', '''x''' | design variable(s) |- | ''g'', '''g''' | constraint(s) |- |} == Terminology == :{| cellpadding="5" width="95%" |- | ''solution'' | The term solution is used in optimization. One solution ('''x''','''f''','''g''') consists of a vector of design variables '''x''', the evaluated objective(s) '''f'''('''x''') and constraint(s) '''g'''('''x''')'''. |- |} 0 47 34 2013-02-15T21:07:50Z Dirk 2 Created page with "= Download Source Code from Subversion Repository = . '''!!!!!!!!!!!!!!!!!!!!!!!''' '''CURRENTLY NOT AVAILABLE''' '''!!!!!!!!!!!!!!!!!!!!!!!''' . The OpenOpal software is ver..." wikitext text/x-wiki = Download Source Code from Subversion Repository = . '''!!!!!!!!!!!!!!!!!!!!!!!''' '''CURRENTLY NOT AVAILABLE''' '''!!!!!!!!!!!!!!!!!!!!!!!''' . The OpenOpal software is version controlled using a Subversion (SVN) repository. In the SVN repository, a "trunk" exist and "branches" might be added. "trunk" contains the main development and should always at least compile and be executable. "branches" are copies of the "trunk" for temporary modifications (see the [http://subversion.tigris.org/ subversion homepage]) and should not be dowloaded. Download the software with shell command: <pre> $ svn checkout {ToDo:Link to SVN}</pre> Downloading requires a [http://subversion.tigris.org/ subversion client] or a [http://subclipse.tigris.org/ subclipse] plugin for [http://www.eclipse.org/ eclipse]. 35 34 2013-02-15T21:08:05Z Dirk 2 /* Download Source Code from Subversion Repository */ wikitext text/x-wiki = Download Source Code = . '''!!!!!!!!!!!!!!!!!!!!!!!''' '''CURRENTLY NOT AVAILABLE''' '''!!!!!!!!!!!!!!!!!!!!!!!''' . The OpenOpal software is version controlled using a Subversion (SVN) repository. In the SVN repository, a "trunk" exist and "branches" might be added. "trunk" contains the main development and should always at least compile and be executable. "branches" are copies of the "trunk" for temporary modifications (see the [http://subversion.tigris.org/ subversion homepage]) and should not be dowloaded. Download the software with shell command: <pre> $ svn checkout {ToDo:Link to SVN}</pre> Downloading requires a [http://subversion.tigris.org/ subversion client] or a [http://subclipse.tigris.org/ subclipse] plugin for [http://www.eclipse.org/ eclipse]. 39 35 2013-02-15T21:25:10Z Dirk 2 /* Download Source Code */ wikitext text/x-wiki = Download Source Code = . '''!!!!!!!!!!!!!!!!!!!!!!!''' '''CURRENTLY NOT AVAILABLE''' '''!!!!!!!!!!!!!!!!!!!!!!!''' . The OpenOpal software is version controlled using a Subversion (SVN) repository. In the SVN repository, a "trunk" exist and "branches" might be added. "trunk" contains the main development and should always at least compile and be executable. "branches" are copies of the "trunk" for temporary modifications (see the [http://subversion.tigris.org/ subversion homepage]) and should not be dowloaded. Download the software with shell command: <pre> $ svn checkout {ToDo:Link to SVN}</pre> Downloading requires a [http://subversion.tigris.org/ subversion client] or an appropriate plug-in for your IDE. 40 39 2013-02-15T21:25:27Z Dirk 2 /* Download Source Code */ wikitext text/x-wiki = Download Source Code = . '''!!!!!!!!!!!!!!!!!!!!!!!''' '''CURRENTLY NOT AVAILABLE''' '''!!!!!!!!!!!!!!!!!!!!!!!''' . The OpenOpal software is version controlled using a Subversion (SVN) repository. In the SVN repository, a "trunk" exist and "branches" might be added. "trunk" contains the main development and should always at least compile and be executable. "branches" are copies of the "trunk" for temporary modifications (see the [http://subversion.tigris.org/ subversion homepage]) and should not be downloaded. Download the software with shell command: <pre> $ svn checkout {ToDo:Link to SVN}</pre> Downloading requires a [http://subversion.tigris.org/ subversion client] or an appropriate plug-in for your IDE. 51 40 2013-02-15T21:51:25Z Admin 1 moved [[Documentation/Download/SVN]] to [[Documentation/Download]] wikitext text/x-wiki = Download Source Code = . '''!!!!!!!!!!!!!!!!!!!!!!!''' '''CURRENTLY NOT AVAILABLE''' '''!!!!!!!!!!!!!!!!!!!!!!!''' . The OpenOpal software is version controlled using a Subversion (SVN) repository. In the SVN repository, a "trunk" exist and "branches" might be added. "trunk" contains the main development and should always at least compile and be executable. "branches" are copies of the "trunk" for temporary modifications (see the [http://subversion.tigris.org/ subversion homepage]) and should not be downloaded. Download the software with shell command: <pre> $ svn checkout {ToDo:Link to SVN}</pre> Downloading requires a [http://subversion.tigris.org/ subversion client] or an appropriate plug-in for your IDE. 53 51 2013-02-15T21:51:57Z Admin 1 /* Download Source Code */ wikitext text/x-wiki == Download Software == . '''!!!!!!!!!!!!!!!!!!!!!!!''' '''CURRENTLY NOT AVAILABLE''' '''!!!!!!!!!!!!!!!!!!!!!!!''' . == Download Source Code == . '''!!!!!!!!!!!!!!!!!!!!!!!''' '''CURRENTLY NOT AVAILABLE''' '''!!!!!!!!!!!!!!!!!!!!!!!''' . The OpenOpal software is version controlled using a Subversion (SVN) repository. In the SVN repository, a "trunk" exist and "branches" might be added. "trunk" contains the main development and should always at least compile and be executable. "branches" are copies of the "trunk" for temporary modifications (see the [http://subversion.tigris.org/ subversion homepage]) and should not be downloaded. Download the software with shell command: <pre> $ svn checkout {ToDo:Link to SVN}</pre> Downloading requires a [http://subversion.tigris.org/ subversion client] or an appropriate plug-in for your IDE. 57 53 2013-02-15T21:55:49Z Admin 1 moved [[Documentation/Download]] to [[Download]] wikitext text/x-wiki == Download Software == . '''!!!!!!!!!!!!!!!!!!!!!!!''' '''CURRENTLY NOT AVAILABLE''' '''!!!!!!!!!!!!!!!!!!!!!!!''' . == Download Source Code == . '''!!!!!!!!!!!!!!!!!!!!!!!''' '''CURRENTLY NOT AVAILABLE''' '''!!!!!!!!!!!!!!!!!!!!!!!''' . The OpenOpal software is version controlled using a Subversion (SVN) repository. In the SVN repository, a "trunk" exist and "branches" might be added. "trunk" contains the main development and should always at least compile and be executable. "branches" are copies of the "trunk" for temporary modifications (see the [http://subversion.tigris.org/ subversion homepage]) and should not be downloaded. Download the software with shell command: <pre> $ svn checkout {ToDo:Link to SVN}</pre> Downloading requires a [http://subversion.tigris.org/ subversion client] or an appropriate plug-in for your IDE. 0 28 37 2013-02-15T21:21:16Z Dirk 2 Created page with "= Developing and Compiling OpenOpal = Check the [[Documentation/Software/Requirements | software requirements]] first! Then [[Documentation/Download/SVN | download]] the source ..." wikitext text/x-wiki = Developing and Compiling OpenOpal = Check the [[Documentation/Software/Requirements | software requirements]] first! Then [[Documentation/Download/SVN | download]] the source code. == Using an IDE == OpenOpal is currently developed with [http://www.netbeans.org/ NetBeans], however other platforms such as Eclipse [http://www.eclipse.org/ Eclipse] can also be used. Nevertheless, compiling and executing the software in a shell is also supported using Makefiles as build system. == Compiling in a Shell == Two platforms are currently tested: <ul> <li><b>Linux: </b> A typical standard implementation of Linux with a Java JDK should contain all required programs for compiling and running OpenOpal. </li> <li><b>Windows: </b> [http://www.cygwin.com/ Cygwin (R)] is used to compile OpenOpal on Windows(R) platforms. </li> </ul> Compiling on other platforms has not been tested. === Creating the Makefile === The Makefile is automatically generated by the script <tt>createMakefile</tt>. In a shell, go to the subfolder <tt>openopal/trunk</tt> and execute: <pre>$ ./createMakefile</pre> Enter <pre>$ make</pre> to list the possible actions. === Compiling the Source Code & Executing OpenOpal === For Linux systems enter <pre>$ make javac $ make gui</pre> to compile and start OpenOpal in GUI mode. For Windows systems enter <pre>$ make javac_cygwin $ make gui</pre> 0 29 38 2013-02-15T21:24:04Z Dirk 2 Created page with "* Compiling: JDK 1.6 or higher * Executing: JRE 1.6 or higher" wikitext text/x-wiki * Compiling: JDK 1.6 or higher * Executing: JRE 1.6 or higher 8 30 49 2013-02-15T21:49:43Z Admin 1 Created page with "* SEARCH * navigation ** mainpage|mainpage-description ** documentation|Documentation ** recentchanges-url|recentchanges ** randompage-url|randompage ** helppage|help * TOOLBOX *..." wikitext text/x-wiki * SEARCH * navigation ** mainpage|mainpage-description ** documentation|Documentation ** recentchanges-url|recentchanges ** randompage-url|randompage ** helppage|help * TOOLBOX * LANGUAGES 50 49 2013-02-15T21:50:51Z Admin 1 wikitext text/x-wiki * SEARCH * navigation ** mainpage|mainpage-description ** documentation|Documentation ** download|download ** recentchanges-url|recentchanges ** randompage-url|randompage * TOOLBOX * LANGUAGES 54 50 2013-02-15T21:52:30Z Admin 1 wikitext text/x-wiki * SEARCH * navigation ** mainpage|mainpage-description ** documentation|Documentation ** download|download-description ** recentchanges-url|recentchanges ** randompage-url|randompage * TOOLBOX * LANGUAGES 55 54 2013-02-15T21:53:32Z Admin 1 wikitext text/x-wiki * SEARCH * navigation ** mainpage|mainpage-description ** documentation|Documentation ** download|Download ** screenshots|Screen Shots ** recentchanges-url|recentchanges ** randompage-url|randompage * TOOLBOX * LANGUAGES 56 55 2013-02-15T21:53:48Z Admin 1 wikitext text/x-wiki * SEARCH * navigation ** mainpage|mainpage-description ** documentation|Documentation ** Download|Download ** screenshots|Screen Shots ** recentchanges-url|recentchanges ** randompage-url|randompage * TOOLBOX * LANGUAGES 59 56 2013-02-15T21:56:28Z Admin 1 wikitext text/x-wiki * SEARCH * navigation ** mainpage|mainpage-description ** documentation|Documentation ** download|Download ** screenshots|Screen Shots ** recentchanges-url|recentchanges ** randompage-url|randompage * TOOLBOX * LANGUAGES 0 31 52 2013-02-15T21:51:25Z Admin 1 moved [[Documentation/Download/SVN]] to [[Documentation/Download]] wikitext text/x-wiki #REDIRECT [[Documentation/Download]] 0 2 60 2 2013-02-15T22:00:12Z Dirk 2 /* Welcome to OpenOpal */ wikitext text/x-wiki = Welcome to '''OpenOpal ''' = '''OpenOpal ''' is an '''Open''' Source software environment for '''OP'''timization '''A'''nd '''L'''earning, providing algorithms for automatic optimization, Design of Experiment, and Machine Learning. The software consists of a '''Core''', a Graphical User Interface ('''GUI''') and '''Module'''s. The Modules comprise all functionality such as optimization algorithm and interfaces to the problem to be optimized. OpenOpal is written in Java. To get into the project: * check the [[Screenshots | Screenshots]] to get an idea about the basic interaction with the software * then, check the [[Documentation | Documentation]]. * or simply [[Download | Download]] the executable jar (no compilation necessary). Contact: * [mailto:help@openopal.org help@openopal.org] 0 33 61 2013-03-18T19:46:17Z Dirk 2 Created page with "=Links and Related Pages= == JAVA Implementations == * Optimization ** [http://www.aridolan.com/ofiles/ga/gaa/gaa.aspx GA Playground] * Neural Network and Data Mining ** [http:..." wikitext text/x-wiki =Links and Related Pages= == JAVA Implementations == * Optimization ** [http://www.aridolan.com/ofiles/ga/gaa/gaa.aspx GA Playground] * Neural Network and Data Mining ** [http://snarli.sourceforge.net/ SNARLI] ** [http://www.cs.waikato.ac.nz/~ml/weka/ WEKA] ** [http://rapid-i.com/ RapidMiner] == MATLAB Implementations == * Optimization ** [http://www.bionik.tu-berlin.de/user/niko/cmaesintro.html Evolution Strategy with Covariance Matrix Adaptation (CMA-ES)] * Neural Network and Data Mining ** [http://www.esat.kuleuven.ac.be/sista/lssvmlab/ Least Squares Support Vector Machines (LS-SVM)] 62 61 2013-03-18T19:48:14Z Dirk 2 wikitext text/x-wiki =Links and Related Pages= == JAVA Implementations == * Optimization ** [http://www.aridolan.com/ofiles/ga/gaa/gaa.aspx GA Playground] * Neural Network and Data Mining ** [http://snarli.sourceforge.net/ SNARLI] ** [http://www.cs.waikato.ac.nz/~ml/weka/ WEKA] ** [http://rapid-i.com/ RapidMiner] == MATLAB Implementations == * Neural Network and Data Mining ** [http://www.esat.kuleuven.ac.be/sista/lssvmlab/ Least Squares Support Vector Machines (LS-SVM)] == Multi-Language Implementations == * Optimization ** [https://www.lri.fr/~hansen/cmaesintro.html Evolution Strategy with Covariance Matrix Adaptation (CMA-ES)] 0 28 63 37 2013-03-18T19:54:09Z Dirk 2 /* Using an IDE */ wikitext text/x-wiki = Developing and Compiling OpenOpal = Check the [[Documentation/Software/Requirements | software requirements]] first! Then [[Documentation/Download/SVN | download]] the source code. == Using an IDE == OpenOpal is currently developed with [http://www.netbeans.org/ NetBeans], as many windows are generated with the Swing framework. However, other platforms such as Eclipse [http://www.eclipse.org/ Eclipse] can also be used. Compiling and executing the software in a shell is also supported using <code>Makefile</code>s as build system. == Compiling in a Shell == Two platforms are currently tested: <ul> <li><b>Linux: </b> A typical standard implementation of Linux with a Java JDK should contain all required programs for compiling and running OpenOpal. </li> <li><b>Windows: </b> [http://www.cygwin.com/ Cygwin (R)] is used to compile OpenOpal on Windows(R) platforms. </li> </ul> Compiling on other platforms has not been tested. === Creating the Makefile === The Makefile is automatically generated by the script <tt>createMakefile</tt>. In a shell, go to the subfolder <tt>openopal/trunk</tt> and execute: <pre>$ ./createMakefile</pre> Enter <pre>$ make</pre> to list the possible actions. === Compiling the Source Code & Executing OpenOpal === For Linux systems enter <pre>$ make javac $ make gui</pre> to compile and start OpenOpal in GUI mode. For Windows systems enter <pre>$ make javac_cygwin $ make gui</pre> 103 63 2013-03-18T21:50:01Z Dirk 2 /* Developing and Compiling OpenOpal */ wikitext text/x-wiki Check the [[Documentation/Software/Requirements | software requirements]] first! Then [[Documentation/Download/SVN | download]] the source code. == Using an IDE == OpenOpal is currently developed with [http://www.netbeans.org/ NetBeans], as many windows are generated with the Swing framework. However, other platforms such as Eclipse [http://www.eclipse.org/ Eclipse] can also be used. Compiling and executing the software in a shell is also supported using <code>Makefile</code>s as build system. == Compiling in a Shell == Two platforms are currently tested: <ul> <li><b>Linux: </b> A typical standard implementation of Linux with a Java JDK should contain all required programs for compiling and running OpenOpal. </li> <li><b>Windows: </b> [http://www.cygwin.com/ Cygwin (R)] is used to compile OpenOpal on Windows(R) platforms. </li> </ul> Compiling on other platforms has not been tested. === Creating the Makefile === The Makefile is automatically generated by the script <tt>createMakefile</tt>. In a shell, go to the subfolder <tt>openopal/trunk</tt> and execute: <pre>$ ./createMakefile</pre> Enter <pre>$ make</pre> to list the possible actions. === Compiling the Source Code & Executing OpenOpal === For Linux systems enter <pre>$ make javac $ make gui</pre> to compile and start OpenOpal in GUI mode. For Windows systems enter <pre>$ make javac_cygwin $ make gui</pre> 0 34 64 2013-03-18T19:57:02Z Dirk 2 Created page with "= Machine Learning = [[Documentation| <-- BACK <--]] == Introduction == Given some data, machine learning infers relations among them. Well known representatives of machine le..." wikitext text/x-wiki = Machine Learning = [[Documentation| <-- BACK <--]] == Introduction == Given some data, machine learning infers relations among them. Well known representatives of machine learning are Artificial Neural Networks and Support Vector Machines. The goal in OpenOpal is to use these techniques to build models either to speed up optimization runs or to post-process the result both [[Documentation/DoE | DoE]] and [[Documentation/Optimization | optimization]]. 65 64 2013-03-18T19:57:17Z Dirk 2 /* Machine Learning */ wikitext text/x-wiki == Introduction == Given some data, machine learning infers relations among them. Well known representatives of machine learning are Artificial Neural Networks and Support Vector Machines. The goal in OpenOpal is to use these techniques to build models either to speed up optimization runs or to post-process the result both [[Documentation/DoE | DoE]] and [[Documentation/Optimization | optimization]]. 0 10 66 41 2013-03-18T19:59:48Z Dirk 2 /* Developers' Guide */ wikitext text/x-wiki == Download == * [[Download | Executable]] * [[Documentation/Download/SVN | Source Code]] * [[Documentation/Software/Requirements | Software Requirements]] == Theory == * [[Documentation/DoE | Introduction to Design of Experiment]] * [[Documentation/Optimization | Introduction to Automated Optimization]] * [[Documentation/Machine_Learning | Introduction to Machine Learning]] * [[Documentation/Notation | Symbols and Notation]] == Users' Guide == * [[screenshots | A First Introduction to OpenOPAL in the Screenshots]] * [[Installation | Installation of OpenOPAL]] * [[Documentation/Modules | Module Documentation of OpenOPAL]] == Developers' Guide == * [[Documentation/Compiling | Developing and Compiling]] * Guidelines for Coding ** [[Documentation/coding/naming | Naming Conventions]] ** [[Documentation/coding/contracts | Contracts]] ** [[Documentation/coding/formatting | Code Formatting]] * Concepts behind OpenOpal ** [[Documentation/Modules/Execution | Module Execution]] ** [[Documentation/Modules/Execution | Module Execution]] ** [[Documentation/Modules/IModule | The Obligatory Interface for Modules]] ** [[Documentation/Modules/Interfaces | Task Specific Interfaces of Modules]] == Various == * [[Documentation/Related | Links and Related Software]] 67 66 2013-03-18T20:00:47Z Dirk 2 /* Developers' Guide */ wikitext text/x-wiki == Download == * [[Download | Executable]] * [[Documentation/Download/SVN | Source Code]] * [[Documentation/Software/Requirements | Software Requirements]] == Theory == * [[Documentation/DoE | Introduction to Design of Experiment]] * [[Documentation/Optimization | Introduction to Automated Optimization]] * [[Documentation/Machine_Learning | Introduction to Machine Learning]] * [[Documentation/Notation | Symbols and Notation]] == Users' Guide == * [[screenshots | A First Introduction to OpenOPAL in the Screenshots]] * [[Installation | Installation of OpenOPAL]] * [[Documentation/Modules | Module Documentation of OpenOPAL]] == Developers' Guide == * [[Documentation/Compiling | Developing and Compiling]] * Concepts behind OpenOpal ** [[Documentation/Modules/Execution | Module Execution]] ** [[Documentation/Modules/Execution | Module Execution]] ** [[Documentation/Modules/IModule | The Obligatory Interface for Modules]] ** [[Documentation/Modules/Interfaces | Task Specific Interfaces of Modules]] == Various == * [[Documentation/Related | Links and Related Software]] 68 67 2013-03-18T20:02:04Z Dirk 2 /* Developers' Guide */ wikitext text/x-wiki == Download == * [[Download | Executable]] * [[Documentation/Download/SVN | Source Code]] * [[Documentation/Software/Requirements | Software Requirements]] == Theory == * [[Documentation/DoE | Introduction to Design of Experiment]] * [[Documentation/Optimization | Introduction to Automated Optimization]] * [[Documentation/Machine_Learning | Introduction to Machine Learning]] * [[Documentation/Notation | Symbols and Notation]] == Users' Guide == * [[screenshots | A First Introduction to OpenOPAL in the Screenshots]] * [[Installation | Installation of OpenOPAL]] * [[Documentation/Modules | Module Documentation of OpenOPAL]] == Developers' Guide == * [[Documentation/Compiling | Developing and Compiling]] * Concepts behind OpenOpal ** [[Documentation/Modules/TheCode | The 3 Main Parts]] ** [[Documentation/Modules/Execution | Module Execution]] ** [[Documentation/Modules/IModule | The Obligatory Interface for Modules]] ** [[Documentation/Modules/Interfaces | Task Specific Interfaces of Modules]] == Various == * [[Documentation/Related | Links and Related Software]] 87 68 2013-03-18T20:42:15Z Dirk 2 /* Developers' Guide */ wikitext text/x-wiki == Download == * [[Download | Executable]] * [[Documentation/Download/SVN | Source Code]] * [[Documentation/Software/Requirements | Software Requirements]] == Theory == * [[Documentation/DoE | Introduction to Design of Experiment]] * [[Documentation/Optimization | Introduction to Automated Optimization]] * [[Documentation/Machine_Learning | Introduction to Machine Learning]] * [[Documentation/Notation | Symbols and Notation]] == Users' Guide == * [[screenshots | A First Introduction to OpenOPAL in the Screenshots]] * [[Installation | Installation of OpenOPAL]] * [[Documentation/Modules | Module Documentation of OpenOPAL]] == Developers' Guide == * [[Documentation/Compiling | Developing and Compiling]] * Concepts behind OpenOpal ** [[Documentation/Modules/TheCode | The 3 Main Parts]] ** [[Documentation/Modules/Execution | Module Execution]] ** [[Documentation/Modules/IModule | Interface <code>IModule</code> - The Obligatory Interface for Modules]] ** [[Documentation/Modules/Interfaces | Task Specific Interfaces of Modules]] == Various == * [[Documentation/Related | Links and Related Software]] 93 87 2013-03-18T21:00:30Z Dirk 2 /* Developers' Guide */ wikitext text/x-wiki == Download == * [[Download | Executable]] * [[Documentation/Download/SVN | Source Code]] * [[Documentation/Software/Requirements | Software Requirements]] == Theory == * [[Documentation/DoE | Introduction to Design of Experiment]] * [[Documentation/Optimization | Introduction to Automated Optimization]] * [[Documentation/Machine_Learning | Introduction to Machine Learning]] * [[Documentation/Notation | Symbols and Notation]] == Users' Guide == * [[screenshots | A First Introduction to OpenOPAL in the Screenshots]] * [[Installation | Installation of OpenOPAL]] * [[Documentation/Modules | Module Documentation of OpenOPAL]] == Developers' Guide == * [[Documentation/Compiling | Developing and Compiling]] * Concepts behind OpenOpal ** [[Documentation/Modules/TheCode | The 3 Main Parts]] ** [[Documentation/Modules/Execution | Module Execution]] ** [[Documentation/Modules/IModule | Interface <code>IModule</code> - The Obligatory Interface for Modules]] ** [[Documentation/Modules/Interfaces | Interfaces of Modules]] ** [[Documentation/Modules/ClassesModules | Abstract Modules and Classes]] == Various == * [[Documentation/Related | Links and Related Software]] 0 35 69 2013-03-18T20:18:04Z Dirk 2 Created page with "OpenOpal consists of 3 parts # the GUI # the Core # many Modules == The GUI == The graphical user interface (GUI) allows setting complex systems by clicking and dragging. It..." wikitext text/x-wiki OpenOpal consists of 3 parts # the GUI # the Core # many Modules == The GUI == The graphical user interface (GUI) allows setting complex systems by clicking and dragging. It allows to add or remove <code>Modules</code> and to define their interactions by so called <code>Connections</code>. == The Core == The <code>Core</code> handles all file operation as well as provides the basic functionality such that <code>Modules</code> can be implemented. == The Modules == The <code>Modules</code> contain all functionality such as optimization algorithms, protocol functions, visualization of results, and optimization problems. All <code>Modules</code> must implement the interface [ <code>IModule</code>] 0 36 70 2013-03-18T20:19:54Z Dirk 2 Created page with "=Interface <tt>IModule</tt>: Guidelines for Writing Modules= All <tt>Modules</tt> in OpenOpal must implement the Interface <tt> IModule</tt>. The interface contains a set of met..." wikitext text/x-wiki =Interface <tt>IModule</tt>: Guidelines for Writing Modules= All <tt>Modules</tt> in OpenOpal must implement the Interface <tt> IModule</tt>. The interface contains a set of methods. The purpose and the functionality of these methods is described in the following sections. It is essential for a correct program execution to ensure that the guidelines are exactly followed by the <i>Module</i> programmers. == Method <tt>Options getOptions()</tt> == # Functionality #* returns the current <tt>Options</tt>. #* ensure that cloned <tt>Options</tt> are returned! # Objectives #* returning a clone of the <tt>Options</tt> ensures that changing <tt>Options</tt> outside the <i>Module</i> has no impact. # Sample Code <pre> public Options getOptions() { return (Options) options.clone(); } </pre> == Method <tt>void setOptions(Options o)</tt> == # Functionality #* sets the <tt>Options</tt> for a Module #* ensure that <tt>Options</tt> are cloned before they are set! # Objectives #* setting a clone of the <tt>Options</tt> ensures that changing <tt>Options</tt> outside the <i>Module</i> has no impact. # Sample Code <pre> public void setOptions(Options o) { options = (Options) o.clone(); } </pre> == Method <tt>String check() </tt> == # Functionality #* check, if this <i>Module</i> is set up correctly, e.g. #** are the <tt>Options</tt> correct? #** are all required Connections of the <i>Module</i> available (e.g. an optimization algorithm may require one connection to a problem) #** do the settings (e.g. Options) agree with the properties of connected <i>Modules</i>? #* checking requires several steps: #*# if the <i>Module</i> is connected to other <i>Modules</i>, it should first #*#* call <tt>check()</tt> of the connected <i>Modules</i> and #*#* return a message, if any connected <i>Module</i>’s check is unsuccessful (i.e. a non-empty string is returned) #*# if checking the connected <i>Modules</i> was successful, the <i>Module</i> should check itself and return a non-empty string if checking fails # Properties #* checks are usually fast # Return Value #* empty string “” if successful, else a message #Sample Code for Optimization: <pre> public String check(){ s = ""; // 1. check connected modules for (Object o: evaluables) { String so=((IModule)o).check(); if (so.length > 0){ s += “checking connected module with ID “ + (IModule o).getID() + “ failed with message: \\n” + so; } } if (s.length > 0){ return “checking connected modules failed: \\n” + s; // 2. check this module, return String if not successful if (opt.verbose > 3) s+= "Option verbose must be between 0 and 3, but is set to " + opt.verbose + "\\n"; // … return s; } </pre> == Method <tt>String init(long SystemTime)</tt> == ( '''ToDo: This does not work System time [milli sec] is too long to guaranty that no conflict.''' ) # Functionality #* initialize <i>Modules</i> such that executing optimizations or learning processes is possible #* Initialization requires several steps: #*# check if the argument (SystemTime) has changed compared to the time of the last check (see also example below). If the argument has not changed, the system has not changed and a new initialization is not necessary. Thus, return the message of the previous check and do no further checking. #*# If the <i>Module</i> is connected to other Modules, it should first #*#* call the <tt>init()</tt> of the connected <i>Modules</i> and #*#* return a message, if any connected <i>Module</i> fails to initialize #*# If the initialization of the connected <i>Modules</i> is successful, it should then get the properties of the connected <i>Modules</i> #*#* return a message, if any connected <i>Module</i> fails to return properties #*# Initialize itself and return a string if initialization fails # Objectives #* initialization should never lead to exceptions #* It must not call <tt>check()</tt>! # Properties #* the <tt>init()</tt> method is the only method of <tt>IModule</tt> that may require CPU time (e.g. for loading a large data source). Thus the SystemTime as argument to this method should help avoiding unnecessary initializations. # Advanced Features #* the <i>Module</i> should check if initialization is necessary. Typically initialization is necessary when #** the <tt>Options</tt> of the <i>Module</i> are changed #** the connections of the <i>Module</i> changed #** the properties of the connected <i>Modules</i> changed #* if nothing changed, it should not initialize in order to save computer resources # Return Value #* empty string “” if successful, else a message # Sample Code for Optimization: <pre> public string init(long init_id){ s = ""; if (this.init_id == init_id){ return [the message of the last initialization]; this.init_id = init_id; for (Object o: evaluables) { String so=((IModule)o).init(init_id); if (so.length > 0){ s += “initializing connected module with ID “ + (IModule o).getID() + “ failed with message: \\n” + so; } } if (s.length > 0){ return “initializing connected modules failed: \\n” + s; // initialize this module, return String if not successful // … return s; } </pre> == Method <tt>int getID()</tt> == # Functionality #* gets the ID for this module # Objectives #* the ID is important for debugging, e.g. <i>Modules</i> can identify to which other <i>Modules</i> they are connected == Method <tt>void setID(int id)</tt> == # Functionality #* sets the ID for this <i>Module</i>. # Objectives #* IDs should be set at the time of instantiation and should not be modified. #* the ID is important for debugging, e.g. <i>Modules</i> can identify to which other <i>Modules</i> they are connected == Method <tt>String getInfo()</tt> == # Functionality #* Returns a String in HTML or plain text, describing the module #* A <i>Module</i> such as an optimization algorithm should return the problem properties when it this <i>Module</i> is called. # Objectives #* get information about <i>Module</i> properties for checking or debugging user settings == Summary == # properties of a <i>Module</i> should only change when the Method <tt>init()</tt> is called. #* this guarantees that <i>Modules</i> do not change while they are checked! = Open Items = * 'path handling for files','The path handling of openopal: files that are eg. written by the protocoller are placed in the source directory of the code. Instead the should be a working directory (e.g. the one where one calls openopal from). In addition, the file browsing dialog should remember the working directory (of the previous call).' * 'Thead save','Methods like evaluate() or init() are currently not thread save. Multiple (optimization) algorithms may call these methods. One solution to this is to synchronize critical methods. ','Methods like evaluate() or init() are currently not thread save. Multiple (optimization) algorithms may call these methods. 71 70 2013-03-18T20:24:13Z Dirk 2 /* Interface IModule: Guidelines for Writing Modules */ wikitext text/x-wiki =Interface <tt>IModule</tt>= All <tt>Modules</tt> in OpenOpal must implement the Interface <tt> IModule</tt>. The interface contains a set of methods. The purpose and the functionality of these methods is described in the following sections. Furthermore, the <tt>Modules</tt> must have a class <tt>Options</tt> that comprises all user settings as simple types (<tt>boolean</tt>, <tt>long</tt>, <tt>double</tt>, <tt>String</tt>) or vectors/arrays of those types. The options are automatically read using Java Reflection API. It is essential for a correct program execution to ensure that the guidelines are exactly followed by the <i>Module</i> programmers. == Method <tt>Options getOptions()</tt> == # Functionality #* returns the current <tt>Options</tt> class. #* ensure that cloned <tt>Options</tt> are returned! # Objectives #* returning a clone of the <tt>Options</tt> ensures that changing <tt>Options</tt> outside the <i>Module</i> has no impact. # Sample Code <pre> public Options getOptions() { return (Options) options.clone(); } </pre> == Method <tt>void setOptions(Options o)</tt> == # Functionality #* sets the <tt>Options</tt> for a Module #* ensure that <tt>Options</tt> are cloned before they are set! # Objectives #* setting a clone of the <tt>Options</tt> ensures that changing <tt>Options</tt> outside the <i>Module</i> has no impact. # Sample Code <pre> public void setOptions(Options o) { options = (Options) o.clone(); } </pre> == Method <tt>String check() </tt> == # Functionality #* check, if this <i>Module</i> is set up correctly, e.g. #** are the <tt>Options</tt> correct? #** are all required Connections of the <i>Module</i> available (e.g. an optimization algorithm may require one connection to a problem) #** do the settings (e.g. Options) agree with the properties of connected <i>Modules</i>? #* checking requires several steps: #*# if the <i>Module</i> is connected to other <i>Modules</i>, it should first #*#* call <tt>check()</tt> of the connected <i>Modules</i> and #*#* return a message, if any connected <i>Module</i>’s check is unsuccessful (i.e. a non-empty string is returned) #*# if checking the connected <i>Modules</i> was successful, the <i>Module</i> should check itself and return a non-empty string if checking fails # Properties #* checks are usually fast # Return Value #* empty string “” if successful, else a message #Sample Code for Optimization: <pre> public String check(){ s = ""; // 1. check connected modules for (Object o: evaluables) { String so=((IModule)o).check(); if (so.length > 0){ s += “checking connected module with ID “ + (IModule o).getID() + “ failed with message: \\n” + so; } } if (s.length > 0){ return “checking connected modules failed: \\n” + s; // 2. check this module, return String if not successful if (opt.verbose > 3) s+= "Option verbose must be between 0 and 3, but is set to " + opt.verbose + "\\n"; // … return s; } </pre> == Method <tt>String init(long SystemTime)</tt> == ( '''ToDo: This does not work System time [milli sec] is too long to guaranty that no conflict.''' ) # Functionality #* initialize <i>Modules</i> such that executing optimizations or learning processes is possible #* Initialization requires several steps: #*# check if the argument (SystemTime) has changed compared to the time of the last check (see also example below). If the argument has not changed, the system has not changed and a new initialization is not necessary. Thus, return the message of the previous check and do no further checking. #*# If the <i>Module</i> is connected to other Modules, it should first #*#* call the <tt>init()</tt> of the connected <i>Modules</i> and #*#* return a message, if any connected <i>Module</i> fails to initialize #*# If the initialization of the connected <i>Modules</i> is successful, it should then get the properties of the connected <i>Modules</i> #*#* return a message, if any connected <i>Module</i> fails to return properties #*# Initialize itself and return a string if initialization fails # Objectives #* initialization should never lead to exceptions #* It must not call <tt>check()</tt>! # Properties #* the <tt>init()</tt> method is the only method of <tt>IModule</tt> that may require CPU time (e.g. for loading a large data source). Thus the SystemTime as argument to this method should help avoiding unnecessary initializations. # Advanced Features #* the <i>Module</i> should check if initialization is necessary. Typically initialization is necessary when #** the <tt>Options</tt> of the <i>Module</i> are changed #** the connections of the <i>Module</i> changed #** the properties of the connected <i>Modules</i> changed #* if nothing changed, it should not initialize in order to save computer resources # Return Value #* empty string “” if successful, else a message # Sample Code for Optimization: <pre> public string init(long init_id){ s = ""; if (this.init_id == init_id){ return [the message of the last initialization]; this.init_id = init_id; for (Object o: evaluables) { String so=((IModule)o).init(init_id); if (so.length > 0){ s += “initializing connected module with ID “ + (IModule o).getID() + “ failed with message: \\n” + so; } } if (s.length > 0){ return “initializing connected modules failed: \\n” + s; // initialize this module, return String if not successful // … return s; } </pre> == Method <tt>int getID()</tt> == # Functionality #* gets the ID for this module # Objectives #* the ID is important for debugging, e.g. <i>Modules</i> can identify to which other <i>Modules</i> they are connected == Method <tt>void setID(int id)</tt> == # Functionality #* sets the ID for this <i>Module</i>. # Objectives #* IDs should be set at the time of instantiation and should not be modified. #* the ID is important for debugging, e.g. <i>Modules</i> can identify to which other <i>Modules</i> they are connected == Method <tt>String getInfo()</tt> == # Functionality #* Returns a String in HTML or plain text, describing the module #* A <i>Module</i> such as an optimization algorithm should return the problem properties when it this <i>Module</i> is called. # Objectives #* get information about <i>Module</i> properties for checking or debugging user settings == Summary == # properties of a <i>Module</i> should only change when the Method <tt>init()</tt> is called. #* this guarantees that <i>Modules</i> do not change while they are checked! = Open Items = * 'path handling for files','The path handling of openopal: files that are eg. written by the protocoller are placed in the source directory of the code. Instead the should be a working directory (e.g. the one where one calls openopal from). In addition, the file browsing dialog should remember the working directory (of the previous call).' * 'Thead save','Methods like evaluate() or init() are currently not thread save. Multiple (optimization) algorithms may call these methods. One solution to this is to synchronize critical methods. ','Methods like evaluate() or init() are currently not thread save. Multiple (optimization) algorithms may call these methods. 72 71 2013-03-18T20:26:48Z Dirk 2 wikitext text/x-wiki =Interface <tt>IModule</tt>= All <tt>Modules</tt> in OpenOpal must implement the Interface <tt> IModule</tt>. The interface contains a set of methods. The purpose and the functionality of these methods is described in the following sections. Furthermore, the <tt>Modules</tt> must have a class <tt>Options</tt> that comprises all user settings as simple types (<tt>boolean</tt>, <tt>long</tt>, <tt>double</tt>, <tt>String</tt>) or vectors/arrays of those types. The options are automatically read using Java Reflection API. It is essential for a correct program execution to ensure that the guidelines are exactly followed by the <tt>Modules</tt> programmers. == Method <tt>Options getOptions()</tt> == # Functionality #* returns the current <tt>Options</tt> class. #* ensure that cloned <tt>Options</tt> are returned! # Objectives #* returning a clone of the <tt>Options</tt> ensures that changing <tt>Options</tt> outside the <tt>Module</tt> has no impact. # Sample Code <pre> public Options getOptions() { return (Options) options.clone(); } </pre> == Method <tt>void setOptions(Options o)</tt> == # Functionality #* sets the <tt>Options</tt> for a Module #* ensure that <tt>Options</tt> are cloned before they are set! # Objectives #* setting a clone of the <tt>Options</tt> ensures that changing <tt>Options</tt> outside the <tt>Modules</tt> has no impact. # Sample Code <pre> public void setOptions(Options o) { options = (Options) o.clone(); } </pre> == Method <tt>String check() </tt> == # Functionality #* check, if this <tt>Modules</tt> is set up correctly, e.g. #** are the <tt>Options</tt> correct? #** are all required Connections of the <tt>Modules</tt> available (e.g. an optimization algorithm may require one connection to a problem) #** do the settings (e.g. Options) agree with the properties of connected <tt>Modules</tt>? #* checking requires several steps: #*# if the<tt>Modules</tt> is connected to other <i>Modules</i>, it should first #*#* call <tt>check()</tt> of the connected <tt>Modules</tt> and #*#* return a message, if any connected<tt>Modules</tt>’s check is unsuccessful (i.e. a non-empty string is returned) #*# if checking the connected <tt>Modules</tt> was successful, the<tt>Modules</tt> should check itself and return a non-empty string if checking fails # Properties #* checks are usually fast # Return Value #* empty string “” if successful, else a message #Sample Code for Optimization: <pre> public String check(){ s = ""; // 1. check connected modules for (Object o: evaluables) { String so=((IModule)o).check(); if (so.length > 0){ s += “checking connected module with ID “ + (IModule o).getID() + “ failed with message: \\n” + so; } } if (s.length > 0){ return “checking connected modules failed: \\n” + s; // 2. check this module, return String if not successful if (opt.verbose > 3) s+= "Option verbose must be between 0 and 3, but is set to " + opt.verbose + "\\n"; // … return s; } </pre> == Method <tt>String init(long SystemTime)</tt> == ( '''ToDo: This does not work System time [milli sec] is too long to guaranty that no conflict.''' ) # Functionality #* initialize <i>Modules</i> such that executing optimizations or learning processes is possible #* Initialization requires several steps: #*# check if the argument (SystemTime) has changed compared to the time of the last check (see also example below). If the argument has not changed, the system has not changed and a new initialization is not necessary. Thus, return the message of the previous check and do no further checking. #*# If the<tt>Modules</tt> is connected to other Modules, it should first #*#* call the <tt>init()</tt> of the connected <i>Modules</i> and #*#* return a message, if any connected<tt>Modules</tt> fails to initialize #*# If the initialization of the connected <i>Modules</i> is successful, it should then get the properties of the connected <i>Modules</i> #*#* return a message, if any connected<tt>Modules</tt> fails to return properties #*# Initialize itself and return a string if initialization fails # Objectives #* initialization should never lead to exceptions #* It must not call <tt>check()</tt>! # Properties #* the <tt>init()</tt> method is the only method of <tt>IModule</tt> that may require CPU time (e.g. for loading a large data source). Thus the SystemTime as argument to this method should help avoiding unnecessary initializations. # Advanced Features #* the<tt>Modules</tt> should check if initialization is necessary. Typically initialization is necessary when #** the <tt>Options</tt> of the<tt>Modules</tt> are changed #** the connections of the<tt>Modules</tt> changed #** the properties of the connected <i>Modules</i> changed #* if nothing changed, it should not initialize in order to save computer resources # Return Value #* empty string “” if successful, else a message # Sample Code for Optimization: <pre> public string init(long init_id){ s = ""; if (this.init_id == init_id){ return [the message of the last initialization]; this.init_id = init_id; for (Object o: evaluables) { String so=((IModule)o).init(init_id); if (so.length > 0){ s += “initializing connected module with ID “ + (IModule o).getID() + “ failed with message: \\n” + so; } } if (s.length > 0){ return “initializing connected modules failed: \\n” + s; // initialize this module, return String if not successful // … return s; } </pre> == Method <tt>int getID()</tt> == # Functionality #* gets the ID for this module # Objectives #* the ID is important for debugging, e.g. <i>Modules</i> can identify to which other <i>Modules</i> they are connected == Method <tt>void setID(int id)</tt> == # Functionality #* sets the ID for this<tt>Modules</tt>. # Objectives #* IDs should be set at the time of instantiation and should not be modified. #* the ID is important for debugging, e.g. <i>Modules</i> can identify to which other <i>Modules</i> they are connected == Method <tt>String getInfo()</tt> == # Functionality #* Returns a String in HTML or plain text, describing the module #* A<tt>Modules</tt> such as an optimization algorithm should return the problem properties when it this<tt>Modules</tt> is called. # Objectives #* get information about<tt>Modules</tt> properties for checking or debugging user settings == Summary == # properties of a<tt>Modules</tt> should only change when the Method <tt>init()</tt> is called. #* this guarantees that <i>Modules</i> do not change while they are checked! = Open Items = * 'path handling for files','The path handling of openopal: files that are eg. written by the protocoller are placed in the source directory of the code. Instead the should be a working directory (e.g. the one where one calls openopal from). In addition, the file browsing dialog should remember the working directory (of the previous call).' * 'Thead save','Methods like evaluate() or init() are currently not thread save. Multiple (optimization) algorithms may call these methods. One solution to this is to synchronize critical methods. ','Methods like evaluate() or init() are currently not thread save. Multiple (optimization) algorithms may call these methods. 73 72 2013-03-18T20:27:15Z Dirk 2 /* Method void setOptions(Options o) */ wikitext text/x-wiki =Interface <tt>IModule</tt>= All <tt>Modules</tt> in OpenOpal must implement the Interface <tt> IModule</tt>. The interface contains a set of methods. The purpose and the functionality of these methods is described in the following sections. Furthermore, the <tt>Modules</tt> must have a class <tt>Options</tt> that comprises all user settings as simple types (<tt>boolean</tt>, <tt>long</tt>, <tt>double</tt>, <tt>String</tt>) or vectors/arrays of those types. The options are automatically read using Java Reflection API. It is essential for a correct program execution to ensure that the guidelines are exactly followed by the <tt>Modules</tt> programmers. == Method <tt>Options getOptions()</tt> == # Functionality #* returns the current <tt>Options</tt> class. #* ensure that cloned <tt>Options</tt> are returned! # Objectives #* returning a clone of the <tt>Options</tt> ensures that changing <tt>Options</tt> outside the <tt>Module</tt> has no impact. # Sample Code <pre> public Options getOptions() { return (Options) options.clone(); } </pre> == Method <tt>void setOptions(Options o)</tt> == # Functionality #* sets the <tt>Options</tt> for a <tt>Module</tt> #* ensure that <tt>Options</tt> are cloned before they are set! # Objectives #* setting a clone of the <tt>Options</tt> ensures that changing <tt>Options</tt> outside the <tt>Modules</tt> has no impact. # Sample Code <pre> public void setOptions(Options o) { options = (Options) o.clone(); } </pre> == Method <tt>String check() </tt> == # Functionality #* check, if this <tt>Modules</tt> is set up correctly, e.g. #** are the <tt>Options</tt> correct? #** are all required Connections of the <tt>Modules</tt> available (e.g. an optimization algorithm may require one connection to a problem) #** do the settings (e.g. Options) agree with the properties of connected <tt>Modules</tt>? #* checking requires several steps: #*# if the<tt>Modules</tt> is connected to other <i>Modules</i>, it should first #*#* call <tt>check()</tt> of the connected <tt>Modules</tt> and #*#* return a message, if any connected<tt>Modules</tt>’s check is unsuccessful (i.e. a non-empty string is returned) #*# if checking the connected <tt>Modules</tt> was successful, the<tt>Modules</tt> should check itself and return a non-empty string if checking fails # Properties #* checks are usually fast # Return Value #* empty string “” if successful, else a message #Sample Code for Optimization: <pre> public String check(){ s = ""; // 1. check connected modules for (Object o: evaluables) { String so=((IModule)o).check(); if (so.length > 0){ s += “checking connected module with ID “ + (IModule o).getID() + “ failed with message: \\n” + so; } } if (s.length > 0){ return “checking connected modules failed: \\n” + s; // 2. check this module, return String if not successful if (opt.verbose > 3) s+= "Option verbose must be between 0 and 3, but is set to " + opt.verbose + "\\n"; // … return s; } </pre> == Method <tt>String init(long SystemTime)</tt> == ( '''ToDo: This does not work System time [milli sec] is too long to guaranty that no conflict.''' ) # Functionality #* initialize <i>Modules</i> such that executing optimizations or learning processes is possible #* Initialization requires several steps: #*# check if the argument (SystemTime) has changed compared to the time of the last check (see also example below). If the argument has not changed, the system has not changed and a new initialization is not necessary. Thus, return the message of the previous check and do no further checking. #*# If the<tt>Modules</tt> is connected to other Modules, it should first #*#* call the <tt>init()</tt> of the connected <i>Modules</i> and #*#* return a message, if any connected<tt>Modules</tt> fails to initialize #*# If the initialization of the connected <i>Modules</i> is successful, it should then get the properties of the connected <i>Modules</i> #*#* return a message, if any connected<tt>Modules</tt> fails to return properties #*# Initialize itself and return a string if initialization fails # Objectives #* initialization should never lead to exceptions #* It must not call <tt>check()</tt>! # Properties #* the <tt>init()</tt> method is the only method of <tt>IModule</tt> that may require CPU time (e.g. for loading a large data source). Thus the SystemTime as argument to this method should help avoiding unnecessary initializations. # Advanced Features #* the<tt>Modules</tt> should check if initialization is necessary. Typically initialization is necessary when #** the <tt>Options</tt> of the<tt>Modules</tt> are changed #** the connections of the<tt>Modules</tt> changed #** the properties of the connected <i>Modules</i> changed #* if nothing changed, it should not initialize in order to save computer resources # Return Value #* empty string “” if successful, else a message # Sample Code for Optimization: <pre> public string init(long init_id){ s = ""; if (this.init_id == init_id){ return [the message of the last initialization]; this.init_id = init_id; for (Object o: evaluables) { String so=((IModule)o).init(init_id); if (so.length > 0){ s += “initializing connected module with ID “ + (IModule o).getID() + “ failed with message: \\n” + so; } } if (s.length > 0){ return “initializing connected modules failed: \\n” + s; // initialize this module, return String if not successful // … return s; } </pre> == Method <tt>int getID()</tt> == # Functionality #* gets the ID for this module # Objectives #* the ID is important for debugging, e.g. <i>Modules</i> can identify to which other <i>Modules</i> they are connected == Method <tt>void setID(int id)</tt> == # Functionality #* sets the ID for this<tt>Modules</tt>. # Objectives #* IDs should be set at the time of instantiation and should not be modified. #* the ID is important for debugging, e.g. <i>Modules</i> can identify to which other <i>Modules</i> they are connected == Method <tt>String getInfo()</tt> == # Functionality #* Returns a String in HTML or plain text, describing the module #* A<tt>Modules</tt> such as an optimization algorithm should return the problem properties when it this<tt>Modules</tt> is called. # Objectives #* get information about<tt>Modules</tt> properties for checking or debugging user settings == Summary == # properties of a<tt>Modules</tt> should only change when the Method <tt>init()</tt> is called. #* this guarantees that <i>Modules</i> do not change while they are checked! = Open Items = * 'path handling for files','The path handling of openopal: files that are eg. written by the protocoller are placed in the source directory of the code. Instead the should be a working directory (e.g. the one where one calls openopal from). In addition, the file browsing dialog should remember the working directory (of the previous call).' * 'Thead save','Methods like evaluate() or init() are currently not thread save. Multiple (optimization) algorithms may call these methods. One solution to this is to synchronize critical methods. ','Methods like evaluate() or init() are currently not thread save. Multiple (optimization) algorithms may call these methods. 74 73 2013-03-18T20:28:30Z Dirk 2 /* Method String check() */ wikitext text/x-wiki =Interface <tt>IModule</tt>= All <tt>Modules</tt> in OpenOpal must implement the Interface <tt> IModule</tt>. The interface contains a set of methods. The purpose and the functionality of these methods is described in the following sections. Furthermore, the <tt>Modules</tt> must have a class <tt>Options</tt> that comprises all user settings as simple types (<tt>boolean</tt>, <tt>long</tt>, <tt>double</tt>, <tt>String</tt>) or vectors/arrays of those types. The options are automatically read using Java Reflection API. It is essential for a correct program execution to ensure that the guidelines are exactly followed by the <tt>Modules</tt> programmers. == Method <tt>Options getOptions()</tt> == # Functionality #* returns the current <tt>Options</tt> class. #* ensure that cloned <tt>Options</tt> are returned! # Objectives #* returning a clone of the <tt>Options</tt> ensures that changing <tt>Options</tt> outside the <tt>Module</tt> has no impact. # Sample Code <pre> public Options getOptions() { return (Options) options.clone(); } </pre> == Method <tt>void setOptions(Options o)</tt> == # Functionality #* sets the <tt>Options</tt> for a <tt>Module</tt> #* ensure that <tt>Options</tt> are cloned before they are set! # Objectives #* setting a clone of the <tt>Options</tt> ensures that changing <tt>Options</tt> outside the <tt>Modules</tt> has no impact. # Sample Code <pre> public void setOptions(Options o) { options = (Options) o.clone(); } </pre> == Method <tt>String check() </tt> == # Functionality #* check, if this <tt>Modules</tt> is set up correctly, i.e. checks if #** the <tt>Options</tt> are correct? #** all required <tt>Connections</tt> of the <tt>Modules</tt> are available (e.g. an optimization algorithm may require one connection to a problem) #** the settings (e.g. Options) agree with the properties of connected <tt>Modules</tt>? #* checking requires several steps: #*# if the<tt>Modules</tt> is connected to other <i>Modules</i>, it should first #*#* call <tt>check()</tt> of the connected <tt>Modules</tt> and #*#* return a message, if any connected<tt>Modules</tt>’s check is unsuccessful (i.e. a non-empty string is returned) #*# if checking the connected <tt>Modules</tt> was successful, the<tt>Modules</tt> should check itself and return a non-empty string if checking fails # Properties #* checks are usually fast # Return Value #* empty string “” if successful, else a message #Sample Code for Optimization: <pre> public String check(){ s = ""; // 1. check connected modules for (Object o: evaluables) { String so=((IModule)o).check(); if (so.length > 0){ s += “checking connected module with ID “ + (IModule o).getID() + “ failed with message: \\n” + so; } } if (s.length > 0){ return “checking connected modules failed: \\n” + s; // 2. check this module, return String if not successful if (opt.verbose > 3) s+= "Option verbose must be between 0 and 3, but is set to " + opt.verbose + "\\n"; // … return s; } </pre> == Method <tt>String init(long SystemTime)</tt> == ( '''ToDo: This does not work System time [milli sec] is too long to guaranty that no conflict.''' ) # Functionality #* initialize <i>Modules</i> such that executing optimizations or learning processes is possible #* Initialization requires several steps: #*# check if the argument (SystemTime) has changed compared to the time of the last check (see also example below). If the argument has not changed, the system has not changed and a new initialization is not necessary. Thus, return the message of the previous check and do no further checking. #*# If the<tt>Modules</tt> is connected to other Modules, it should first #*#* call the <tt>init()</tt> of the connected <i>Modules</i> and #*#* return a message, if any connected<tt>Modules</tt> fails to initialize #*# If the initialization of the connected <i>Modules</i> is successful, it should then get the properties of the connected <i>Modules</i> #*#* return a message, if any connected<tt>Modules</tt> fails to return properties #*# Initialize itself and return a string if initialization fails # Objectives #* initialization should never lead to exceptions #* It must not call <tt>check()</tt>! # Properties #* the <tt>init()</tt> method is the only method of <tt>IModule</tt> that may require CPU time (e.g. for loading a large data source). Thus the SystemTime as argument to this method should help avoiding unnecessary initializations. # Advanced Features #* the<tt>Modules</tt> should check if initialization is necessary. Typically initialization is necessary when #** the <tt>Options</tt> of the<tt>Modules</tt> are changed #** the connections of the<tt>Modules</tt> changed #** the properties of the connected <i>Modules</i> changed #* if nothing changed, it should not initialize in order to save computer resources # Return Value #* empty string “” if successful, else a message # Sample Code for Optimization: <pre> public string init(long init_id){ s = ""; if (this.init_id == init_id){ return [the message of the last initialization]; this.init_id = init_id; for (Object o: evaluables) { String so=((IModule)o).init(init_id); if (so.length > 0){ s += “initializing connected module with ID “ + (IModule o).getID() + “ failed with message: \\n” + so; } } if (s.length > 0){ return “initializing connected modules failed: \\n” + s; // initialize this module, return String if not successful // … return s; } </pre> == Method <tt>int getID()</tt> == # Functionality #* gets the ID for this module # Objectives #* the ID is important for debugging, e.g. <i>Modules</i> can identify to which other <i>Modules</i> they are connected == Method <tt>void setID(int id)</tt> == # Functionality #* sets the ID for this<tt>Modules</tt>. # Objectives #* IDs should be set at the time of instantiation and should not be modified. #* the ID is important for debugging, e.g. <i>Modules</i> can identify to which other <i>Modules</i> they are connected == Method <tt>String getInfo()</tt> == # Functionality #* Returns a String in HTML or plain text, describing the module #* A<tt>Modules</tt> such as an optimization algorithm should return the problem properties when it this<tt>Modules</tt> is called. # Objectives #* get information about<tt>Modules</tt> properties for checking or debugging user settings == Summary == # properties of a<tt>Modules</tt> should only change when the Method <tt>init()</tt> is called. #* this guarantees that <i>Modules</i> do not change while they are checked! = Open Items = * 'path handling for files','The path handling of openopal: files that are eg. written by the protocoller are placed in the source directory of the code. Instead the should be a working directory (e.g. the one where one calls openopal from). In addition, the file browsing dialog should remember the working directory (of the previous call).' * 'Thead save','Methods like evaluate() or init() are currently not thread save. Multiple (optimization) algorithms may call these methods. One solution to this is to synchronize critical methods. ','Methods like evaluate() or init() are currently not thread save. Multiple (optimization) algorithms may call these methods. 75 74 2013-03-18T20:28:54Z Dirk 2 /* Method String check() */ wikitext text/x-wiki =Interface <tt>IModule</tt>= All <tt>Modules</tt> in OpenOpal must implement the Interface <tt> IModule</tt>. The interface contains a set of methods. The purpose and the functionality of these methods is described in the following sections. Furthermore, the <tt>Modules</tt> must have a class <tt>Options</tt> that comprises all user settings as simple types (<tt>boolean</tt>, <tt>long</tt>, <tt>double</tt>, <tt>String</tt>) or vectors/arrays of those types. The options are automatically read using Java Reflection API. It is essential for a correct program execution to ensure that the guidelines are exactly followed by the <tt>Modules</tt> programmers. == Method <tt>Options getOptions()</tt> == # Functionality #* returns the current <tt>Options</tt> class. #* ensure that cloned <tt>Options</tt> are returned! # Objectives #* returning a clone of the <tt>Options</tt> ensures that changing <tt>Options</tt> outside the <tt>Module</tt> has no impact. # Sample Code <pre> public Options getOptions() { return (Options) options.clone(); } </pre> == Method <tt>void setOptions(Options o)</tt> == # Functionality #* sets the <tt>Options</tt> for a <tt>Module</tt> #* ensure that <tt>Options</tt> are cloned before they are set! # Objectives #* setting a clone of the <tt>Options</tt> ensures that changing <tt>Options</tt> outside the <tt>Modules</tt> has no impact. # Sample Code <pre> public void setOptions(Options o) { options = (Options) o.clone(); } </pre> == Method <tt>String check() </tt> == # Functionality #* check, if this <tt>Modules</tt> is set up correctly, i.e. checks if #** the <tt>Options</tt> are correct? #** all required <tt>Connections</tt> of the <tt>Modules</tt> are available (e.g. an optimization algorithm may require one connection to a problem) #** the settings (e.g. Options) agree with the properties of connected <tt>Modules</tt>? #* checking requires several steps: #*# if the <tt>Modules</tt> is connected to other <tt>Modules</tt>, it should first #*#* call <tt>check()</tt> of the connected <tt>Modules</tt> and #*#* return a message, if any connected<tt>Modules</tt>’s check is unsuccessful (i.e. a non-empty string is returned) #*# if checking the connected <tt>Modules</tt> was successful, the<tt>Modules</tt> should check itself and return a non-empty string if checking fails # Properties #* checks are usually fast # Return Value #* empty string “” if successful, else a message #Sample Code for Optimization: <pre> public String check(){ s = ""; // 1. check connected modules for (Object o: evaluables) { String so=((IModule)o).check(); if (so.length > 0){ s += “checking connected module with ID “ + (IModule o).getID() + “ failed with message: \\n” + so; } } if (s.length > 0){ return “checking connected modules failed: \\n” + s; // 2. check this module, return String if not successful if (opt.verbose > 3) s+= "Option verbose must be between 0 and 3, but is set to " + opt.verbose + "\\n"; // … return s; } </pre> == Method <tt>String init(long SystemTime)</tt> == ( '''ToDo: This does not work System time [milli sec] is too long to guaranty that no conflict.''' ) # Functionality #* initialize <i>Modules</i> such that executing optimizations or learning processes is possible #* Initialization requires several steps: #*# check if the argument (SystemTime) has changed compared to the time of the last check (see also example below). If the argument has not changed, the system has not changed and a new initialization is not necessary. Thus, return the message of the previous check and do no further checking. #*# If the<tt>Modules</tt> is connected to other Modules, it should first #*#* call the <tt>init()</tt> of the connected <i>Modules</i> and #*#* return a message, if any connected<tt>Modules</tt> fails to initialize #*# If the initialization of the connected <i>Modules</i> is successful, it should then get the properties of the connected <i>Modules</i> #*#* return a message, if any connected<tt>Modules</tt> fails to return properties #*# Initialize itself and return a string if initialization fails # Objectives #* initialization should never lead to exceptions #* It must not call <tt>check()</tt>! # Properties #* the <tt>init()</tt> method is the only method of <tt>IModule</tt> that may require CPU time (e.g. for loading a large data source). Thus the SystemTime as argument to this method should help avoiding unnecessary initializations. # Advanced Features #* the<tt>Modules</tt> should check if initialization is necessary. Typically initialization is necessary when #** the <tt>Options</tt> of the<tt>Modules</tt> are changed #** the connections of the<tt>Modules</tt> changed #** the properties of the connected <i>Modules</i> changed #* if nothing changed, it should not initialize in order to save computer resources # Return Value #* empty string “” if successful, else a message # Sample Code for Optimization: <pre> public string init(long init_id){ s = ""; if (this.init_id == init_id){ return [the message of the last initialization]; this.init_id = init_id; for (Object o: evaluables) { String so=((IModule)o).init(init_id); if (so.length > 0){ s += “initializing connected module with ID “ + (IModule o).getID() + “ failed with message: \\n” + so; } } if (s.length > 0){ return “initializing connected modules failed: \\n” + s; // initialize this module, return String if not successful // … return s; } </pre> == Method <tt>int getID()</tt> == # Functionality #* gets the ID for this module # Objectives #* the ID is important for debugging, e.g. <i>Modules</i> can identify to which other <i>Modules</i> they are connected == Method <tt>void setID(int id)</tt> == # Functionality #* sets the ID for this<tt>Modules</tt>. # Objectives #* IDs should be set at the time of instantiation and should not be modified. #* the ID is important for debugging, e.g. <i>Modules</i> can identify to which other <i>Modules</i> they are connected == Method <tt>String getInfo()</tt> == # Functionality #* Returns a String in HTML or plain text, describing the module #* A<tt>Modules</tt> such as an optimization algorithm should return the problem properties when it this<tt>Modules</tt> is called. # Objectives #* get information about<tt>Modules</tt> properties for checking or debugging user settings == Summary == # properties of a<tt>Modules</tt> should only change when the Method <tt>init()</tt> is called. #* this guarantees that <i>Modules</i> do not change while they are checked! = Open Items = * 'path handling for files','The path handling of openopal: files that are eg. written by the protocoller are placed in the source directory of the code. Instead the should be a working directory (e.g. the one where one calls openopal from). In addition, the file browsing dialog should remember the working directory (of the previous call).' * 'Thead save','Methods like evaluate() or init() are currently not thread save. Multiple (optimization) algorithms may call these methods. One solution to this is to synchronize critical methods. ','Methods like evaluate() or init() are currently not thread save. Multiple (optimization) algorithms may call these methods. 76 75 2013-03-18T20:29:35Z Dirk 2 /* Method String check() */ wikitext text/x-wiki =Interface <tt>IModule</tt>= All <tt>Modules</tt> in OpenOpal must implement the Interface <tt> IModule</tt>. The interface contains a set of methods. The purpose and the functionality of these methods is described in the following sections. Furthermore, the <tt>Modules</tt> must have a class <tt>Options</tt> that comprises all user settings as simple types (<tt>boolean</tt>, <tt>long</tt>, <tt>double</tt>, <tt>String</tt>) or vectors/arrays of those types. The options are automatically read using Java Reflection API. It is essential for a correct program execution to ensure that the guidelines are exactly followed by the <tt>Modules</tt> programmers. == Method <tt>Options getOptions()</tt> == # Functionality #* returns the current <tt>Options</tt> class. #* ensure that cloned <tt>Options</tt> are returned! # Objectives #* returning a clone of the <tt>Options</tt> ensures that changing <tt>Options</tt> outside the <tt>Module</tt> has no impact. # Sample Code <pre> public Options getOptions() { return (Options) options.clone(); } </pre> == Method <tt>void setOptions(Options o)</tt> == # Functionality #* sets the <tt>Options</tt> for a <tt>Module</tt> #* ensure that <tt>Options</tt> are cloned before they are set! # Objectives #* setting a clone of the <tt>Options</tt> ensures that changing <tt>Options</tt> outside the <tt>Modules</tt> has no impact. # Sample Code <pre> public void setOptions(Options o) { options = (Options) o.clone(); } </pre> == Method <tt>String check() </tt> == # Functionality #* check, if this <tt>Modules</tt> is set up correctly, i.e. checks if #** the <tt>Options</tt> are correct? #** all required <tt>Connections</tt> of the <tt>Modules</tt> are available (e.g. an optimization algorithm may require one connection to a problem) #** the settings (e.g. Options) agree with the properties of connected <tt>Modules</tt>? #* checking requires several steps: #*# if the <tt>Modules</tt> is connected to other <tt>Modules</tt>, it should first #*#* call <tt>check()</tt> of the connected <tt>Modules</tt> and #*#* return a message, if any connected <tt>Modules</tt>’s check is unsuccessful (i.e. a non-empty string is returned). #*# if checking the connected <tt>Modules</tt> was successful, the <tt>Modules</tt> should check itself and return a non-empty string if checking fails. # Properties #* checks are usually fast # Return Value #* empty string “” if successful, else a message #Sample Code for Optimization: <pre> public String check(){ s = ""; // 1. check connected modules for (Object o: evaluables) { String so=((IModule)o).check(); if (so.length > 0){ s += “checking connected module with ID “ + (IModule o).getID() + “ failed with message: \\n” + so; } } if (s.length > 0){ return “checking connected modules failed: \\n” + s; // 2. check this module, return String if not successful if (opt.verbose > 3) s+= "Option verbose must be between 0 and 3, but is set to " + opt.verbose + "\\n"; // … return s; } </pre> == Method <tt>String init(long SystemTime)</tt> == ( '''ToDo: This does not work System time [milli sec] is too long to guaranty that no conflict.''' ) # Functionality #* initialize <i>Modules</i> such that executing optimizations or learning processes is possible #* Initialization requires several steps: #*# check if the argument (SystemTime) has changed compared to the time of the last check (see also example below). If the argument has not changed, the system has not changed and a new initialization is not necessary. Thus, return the message of the previous check and do no further checking. #*# If the<tt>Modules</tt> is connected to other Modules, it should first #*#* call the <tt>init()</tt> of the connected <i>Modules</i> and #*#* return a message, if any connected<tt>Modules</tt> fails to initialize #*# If the initialization of the connected <i>Modules</i> is successful, it should then get the properties of the connected <i>Modules</i> #*#* return a message, if any connected<tt>Modules</tt> fails to return properties #*# Initialize itself and return a string if initialization fails # Objectives #* initialization should never lead to exceptions #* It must not call <tt>check()</tt>! # Properties #* the <tt>init()</tt> method is the only method of <tt>IModule</tt> that may require CPU time (e.g. for loading a large data source). Thus the SystemTime as argument to this method should help avoiding unnecessary initializations. # Advanced Features #* the<tt>Modules</tt> should check if initialization is necessary. Typically initialization is necessary when #** the <tt>Options</tt> of the<tt>Modules</tt> are changed #** the connections of the<tt>Modules</tt> changed #** the properties of the connected <i>Modules</i> changed #* if nothing changed, it should not initialize in order to save computer resources # Return Value #* empty string “” if successful, else a message # Sample Code for Optimization: <pre> public string init(long init_id){ s = ""; if (this.init_id == init_id){ return [the message of the last initialization]; this.init_id = init_id; for (Object o: evaluables) { String so=((IModule)o).init(init_id); if (so.length > 0){ s += “initializing connected module with ID “ + (IModule o).getID() + “ failed with message: \\n” + so; } } if (s.length > 0){ return “initializing connected modules failed: \\n” + s; // initialize this module, return String if not successful // … return s; } </pre> == Method <tt>int getID()</tt> == # Functionality #* gets the ID for this module # Objectives #* the ID is important for debugging, e.g. <i>Modules</i> can identify to which other <i>Modules</i> they are connected == Method <tt>void setID(int id)</tt> == # Functionality #* sets the ID for this<tt>Modules</tt>. # Objectives #* IDs should be set at the time of instantiation and should not be modified. #* the ID is important for debugging, e.g. <i>Modules</i> can identify to which other <i>Modules</i> they are connected == Method <tt>String getInfo()</tt> == # Functionality #* Returns a String in HTML or plain text, describing the module #* A<tt>Modules</tt> such as an optimization algorithm should return the problem properties when it this<tt>Modules</tt> is called. # Objectives #* get information about<tt>Modules</tt> properties for checking or debugging user settings == Summary == # properties of a<tt>Modules</tt> should only change when the Method <tt>init()</tt> is called. #* this guarantees that <i>Modules</i> do not change while they are checked! = Open Items = * 'path handling for files','The path handling of openopal: files that are eg. written by the protocoller are placed in the source directory of the code. Instead the should be a working directory (e.g. the one where one calls openopal from). In addition, the file browsing dialog should remember the working directory (of the previous call).' * 'Thead save','Methods like evaluate() or init() are currently not thread save. Multiple (optimization) algorithms may call these methods. One solution to this is to synchronize critical methods. ','Methods like evaluate() or init() are currently not thread save. Multiple (optimization) algorithms may call these methods. 77 76 2013-03-18T20:31:11Z Dirk 2 /* Method String init(long SystemTime) */ wikitext text/x-wiki =Interface <tt>IModule</tt>= All <tt>Modules</tt> in OpenOpal must implement the Interface <tt> IModule</tt>. The interface contains a set of methods. The purpose and the functionality of these methods is described in the following sections. Furthermore, the <tt>Modules</tt> must have a class <tt>Options</tt> that comprises all user settings as simple types (<tt>boolean</tt>, <tt>long</tt>, <tt>double</tt>, <tt>String</tt>) or vectors/arrays of those types. The options are automatically read using Java Reflection API. It is essential for a correct program execution to ensure that the guidelines are exactly followed by the <tt>Modules</tt> programmers. == Method <tt>Options getOptions()</tt> == # Functionality #* returns the current <tt>Options</tt> class. #* ensure that cloned <tt>Options</tt> are returned! # Objectives #* returning a clone of the <tt>Options</tt> ensures that changing <tt>Options</tt> outside the <tt>Module</tt> has no impact. # Sample Code <pre> public Options getOptions() { return (Options) options.clone(); } </pre> == Method <tt>void setOptions(Options o)</tt> == # Functionality #* sets the <tt>Options</tt> for a <tt>Module</tt> #* ensure that <tt>Options</tt> are cloned before they are set! # Objectives #* setting a clone of the <tt>Options</tt> ensures that changing <tt>Options</tt> outside the <tt>Modules</tt> has no impact. # Sample Code <pre> public void setOptions(Options o) { options = (Options) o.clone(); } </pre> == Method <tt>String check() </tt> == # Functionality #* check, if this <tt>Modules</tt> is set up correctly, i.e. checks if #** the <tt>Options</tt> are correct? #** all required <tt>Connections</tt> of the <tt>Modules</tt> are available (e.g. an optimization algorithm may require one connection to a problem) #** the settings (e.g. Options) agree with the properties of connected <tt>Modules</tt>? #* checking requires several steps: #*# if the <tt>Modules</tt> is connected to other <tt>Modules</tt>, it should first #*#* call <tt>check()</tt> of the connected <tt>Modules</tt> and #*#* return a message, if any connected <tt>Modules</tt>’s check is unsuccessful (i.e. a non-empty string is returned). #*# if checking the connected <tt>Modules</tt> was successful, the <tt>Modules</tt> should check itself and return a non-empty string if checking fails. # Properties #* checks are usually fast # Return Value #* empty string “” if successful, else a message #Sample Code for Optimization: <pre> public String check(){ s = ""; // 1. check connected modules for (Object o: evaluables) { String so=((IModule)o).check(); if (so.length > 0){ s += “checking connected module with ID “ + (IModule o).getID() + “ failed with message: \\n” + so; } } if (s.length > 0){ return “checking connected modules failed: \\n” + s; // 2. check this module, return String if not successful if (opt.verbose > 3) s+= "Option verbose must be between 0 and 3, but is set to " + opt.verbose + "\\n"; // … return s; } </pre> == Method <tt>String init(long index)</tt> == Currently the <tt>index</tt> is not used! # Functionality #* initialize <i>Modules</i> such that executing optimizations or learning processes is possible #* Initialization requires several steps: #*# check if the argument (SystemTime) has changed compared to the time of the last check (see also example below). If the argument has not changed, the system has not changed and a new initialization is not necessary. Thus, return the message of the previous check and do no further checking. #*# If the<tt>Modules</tt> is connected to other Modules, it should first #*#* call the <tt>init()</tt> of the connected <i>Modules</i> and #*#* return a message, if any connected<tt>Modules</tt> fails to initialize #*# If the initialization of the connected <i>Modules</i> is successful, it should then get the properties of the connected <i>Modules</i> #*#* return a message, if any connected<tt>Modules</tt> fails to return properties #*# Initialize itself and return a string if initialization fails # Objectives #* initialization should never lead to exceptions #* It must not call <tt>check()</tt>! # Properties #* the <tt>init()</tt> method is the only method of <tt>IModule</tt> that may require CPU time (e.g. for loading a large data source). Thus the SystemTime as argument to this method should help avoiding unnecessary initializations. # Advanced Features #* the<tt>Modules</tt> should check if initialization is necessary. Typically initialization is necessary when #** the <tt>Options</tt> of the<tt>Modules</tt> are changed #** the connections of the<tt>Modules</tt> changed #** the properties of the connected <i>Modules</i> changed #* if nothing changed, it should not initialize in order to save computer resources # Return Value #* empty string “” if successful, else a message # Sample Code for Optimization: <pre> public string init(long init_id){ s = ""; if (this.init_id == init_id){ return [the message of the last initialization]; this.init_id = init_id; for (Object o: evaluables) { String so=((IModule)o).init(init_id); if (so.length > 0){ s += “initializing connected module with ID “ + (IModule o).getID() + “ failed with message: \\n” + so; } } if (s.length > 0){ return “initializing connected modules failed: \\n” + s; // initialize this module, return String if not successful // … return s; } </pre> == Method <tt>int getID()</tt> == # Functionality #* gets the ID for this module # Objectives #* the ID is important for debugging, e.g. <i>Modules</i> can identify to which other <i>Modules</i> they are connected == Method <tt>void setID(int id)</tt> == # Functionality #* sets the ID for this<tt>Modules</tt>. # Objectives #* IDs should be set at the time of instantiation and should not be modified. #* the ID is important for debugging, e.g. <i>Modules</i> can identify to which other <i>Modules</i> they are connected == Method <tt>String getInfo()</tt> == # Functionality #* Returns a String in HTML or plain text, describing the module #* A<tt>Modules</tt> such as an optimization algorithm should return the problem properties when it this<tt>Modules</tt> is called. # Objectives #* get information about<tt>Modules</tt> properties for checking or debugging user settings == Summary == # properties of a<tt>Modules</tt> should only change when the Method <tt>init()</tt> is called. #* this guarantees that <i>Modules</i> do not change while they are checked! = Open Items = * 'path handling for files','The path handling of openopal: files that are eg. written by the protocoller are placed in the source directory of the code. Instead the should be a working directory (e.g. the one where one calls openopal from). In addition, the file browsing dialog should remember the working directory (of the previous call).' * 'Thead save','Methods like evaluate() or init() are currently not thread save. Multiple (optimization) algorithms may call these methods. One solution to this is to synchronize critical methods. ','Methods like evaluate() or init() are currently not thread save. Multiple (optimization) algorithms may call these methods. 78 77 2013-03-18T20:33:23Z Dirk 2 /* Method String init(long index) */ wikitext text/x-wiki =Interface <tt>IModule</tt>= All <tt>Modules</tt> in OpenOpal must implement the Interface <tt> IModule</tt>. The interface contains a set of methods. The purpose and the functionality of these methods is described in the following sections. Furthermore, the <tt>Modules</tt> must have a class <tt>Options</tt> that comprises all user settings as simple types (<tt>boolean</tt>, <tt>long</tt>, <tt>double</tt>, <tt>String</tt>) or vectors/arrays of those types. The options are automatically read using Java Reflection API. It is essential for a correct program execution to ensure that the guidelines are exactly followed by the <tt>Modules</tt> programmers. == Method <tt>Options getOptions()</tt> == # Functionality #* returns the current <tt>Options</tt> class. #* ensure that cloned <tt>Options</tt> are returned! # Objectives #* returning a clone of the <tt>Options</tt> ensures that changing <tt>Options</tt> outside the <tt>Module</tt> has no impact. # Sample Code <pre> public Options getOptions() { return (Options) options.clone(); } </pre> == Method <tt>void setOptions(Options o)</tt> == # Functionality #* sets the <tt>Options</tt> for a <tt>Module</tt> #* ensure that <tt>Options</tt> are cloned before they are set! # Objectives #* setting a clone of the <tt>Options</tt> ensures that changing <tt>Options</tt> outside the <tt>Modules</tt> has no impact. # Sample Code <pre> public void setOptions(Options o) { options = (Options) o.clone(); } </pre> == Method <tt>String check() </tt> == # Functionality #* check, if this <tt>Modules</tt> is set up correctly, i.e. checks if #** the <tt>Options</tt> are correct? #** all required <tt>Connections</tt> of the <tt>Modules</tt> are available (e.g. an optimization algorithm may require one connection to a problem) #** the settings (e.g. Options) agree with the properties of connected <tt>Modules</tt>? #* checking requires several steps: #*# if the <tt>Modules</tt> is connected to other <tt>Modules</tt>, it should first #*#* call <tt>check()</tt> of the connected <tt>Modules</tt> and #*#* return a message, if any connected <tt>Modules</tt>’s check is unsuccessful (i.e. a non-empty string is returned). #*# if checking the connected <tt>Modules</tt> was successful, the <tt>Modules</tt> should check itself and return a non-empty string if checking fails. # Properties #* checks are usually fast # Return Value #* empty string “” if successful, else a message #Sample Code for Optimization: <pre> public String check(){ s = ""; // 1. check connected modules for (Object o: evaluables) { String so=((IModule)o).check(); if (so.length > 0){ s += “checking connected module with ID “ + (IModule o).getID() + “ failed with message: \\n” + so; } } if (s.length > 0){ return “checking connected modules failed: \\n” + s; // 2. check this module, return String if not successful if (opt.verbose > 3) s+= "Option verbose must be between 0 and 3, but is set to " + opt.verbose + "\\n"; // … return s; } </pre> == Method <tt>String init(long index)</tt> == Currently the <tt>index</tt> is not used! # Functionality #* initialize <tt>Modules</tt> such that executing optimizations or learning processes is possible. #* Initialization requires several steps: #*# check if the argument (index) has changed compared to the time of the last check (see also example below). If the argument has not changed, the system has not changed and a new initialization is not necessary. Thus, return the message of the previous check and do no further checking. #*# If the <tt>Modules</tt> is connected to other Modules, it should first #*#* call the <tt>init()</tt> of the connected <tt>Modules</tt> and #*#* return a message, if any connected <tt>Modules</tt> fails to initialize #*# If the initialization of the connected <tt>Modules</tt> is successful, it should then get the properties of the connected <tt>Modules</tt> #*#* return a message, if any connected <tt>Modules</tt> fails to return properties. #*# Initialize itself and return a string if initialization fails. # Objectives #* initialization should never lead to exceptions. #* It must not call <tt>check()</tt>! # Properties #* the <tt>init()</tt> method is the only method of <tt>IModule</tt> that may require CPU time (e.g. for loading a large data source). Thus this method should not be called too often. # Advanced Features #* the<tt>Modules</tt> should check if initialization is necessary. Typically initialization is necessary when #** the <tt>Options</tt> of the<tt>Modules</tt> are changed #** the connections of the<tt>Modules</tt> changed #** the properties of the connected <i>Modules</i> changed #* if nothing changed, it should not initialize in order to save computer resources # Return Value #* empty string “” if successful, else a message # Sample Code for Optimization: <pre> public string init(long init_id){ s = ""; if (this.init_id == init_id){ return [the message of the last initialization]; this.init_id = init_id; for (Object o: evaluables) { String so=((IModule)o).init(init_id); if (so.length > 0){ s += “initializing connected module with ID “ + (IModule o).getID() + “ failed with message: \\n” + so; } } if (s.length > 0){ return “initializing connected modules failed: \\n” + s; // initialize this module, return String if not successful // … return s; } </pre> == Method <tt>int getID()</tt> == # Functionality #* gets the ID for this module # Objectives #* the ID is important for debugging, e.g. <i>Modules</i> can identify to which other <i>Modules</i> they are connected == Method <tt>void setID(int id)</tt> == # Functionality #* sets the ID for this<tt>Modules</tt>. # Objectives #* IDs should be set at the time of instantiation and should not be modified. #* the ID is important for debugging, e.g. <i>Modules</i> can identify to which other <i>Modules</i> they are connected == Method <tt>String getInfo()</tt> == # Functionality #* Returns a String in HTML or plain text, describing the module #* A<tt>Modules</tt> such as an optimization algorithm should return the problem properties when it this<tt>Modules</tt> is called. # Objectives #* get information about<tt>Modules</tt> properties for checking or debugging user settings == Summary == # properties of a<tt>Modules</tt> should only change when the Method <tt>init()</tt> is called. #* this guarantees that <i>Modules</i> do not change while they are checked! = Open Items = * 'path handling for files','The path handling of openopal: files that are eg. written by the protocoller are placed in the source directory of the code. Instead the should be a working directory (e.g. the one where one calls openopal from). In addition, the file browsing dialog should remember the working directory (of the previous call).' * 'Thead save','Methods like evaluate() or init() are currently not thread save. Multiple (optimization) algorithms may call these methods. One solution to this is to synchronize critical methods. ','Methods like evaluate() or init() are currently not thread save. Multiple (optimization) algorithms may call these methods. 79 78 2013-03-18T20:34:40Z Dirk 2 /* Method int getID() */ wikitext text/x-wiki =Interface <tt>IModule</tt>= All <tt>Modules</tt> in OpenOpal must implement the Interface <tt> IModule</tt>. The interface contains a set of methods. The purpose and the functionality of these methods is described in the following sections. Furthermore, the <tt>Modules</tt> must have a class <tt>Options</tt> that comprises all user settings as simple types (<tt>boolean</tt>, <tt>long</tt>, <tt>double</tt>, <tt>String</tt>) or vectors/arrays of those types. The options are automatically read using Java Reflection API. It is essential for a correct program execution to ensure that the guidelines are exactly followed by the <tt>Modules</tt> programmers. == Method <tt>Options getOptions()</tt> == # Functionality #* returns the current <tt>Options</tt> class. #* ensure that cloned <tt>Options</tt> are returned! # Objectives #* returning a clone of the <tt>Options</tt> ensures that changing <tt>Options</tt> outside the <tt>Module</tt> has no impact. # Sample Code <pre> public Options getOptions() { return (Options) options.clone(); } </pre> == Method <tt>void setOptions(Options o)</tt> == # Functionality #* sets the <tt>Options</tt> for a <tt>Module</tt> #* ensure that <tt>Options</tt> are cloned before they are set! # Objectives #* setting a clone of the <tt>Options</tt> ensures that changing <tt>Options</tt> outside the <tt>Modules</tt> has no impact. # Sample Code <pre> public void setOptions(Options o) { options = (Options) o.clone(); } </pre> == Method <tt>String check() </tt> == # Functionality #* check, if this <tt>Modules</tt> is set up correctly, i.e. checks if #** the <tt>Options</tt> are correct? #** all required <tt>Connections</tt> of the <tt>Modules</tt> are available (e.g. an optimization algorithm may require one connection to a problem) #** the settings (e.g. Options) agree with the properties of connected <tt>Modules</tt>? #* checking requires several steps: #*# if the <tt>Modules</tt> is connected to other <tt>Modules</tt>, it should first #*#* call <tt>check()</tt> of the connected <tt>Modules</tt> and #*#* return a message, if any connected <tt>Modules</tt>’s check is unsuccessful (i.e. a non-empty string is returned). #*# if checking the connected <tt>Modules</tt> was successful, the <tt>Modules</tt> should check itself and return a non-empty string if checking fails. # Properties #* checks are usually fast # Return Value #* empty string “” if successful, else a message #Sample Code for Optimization: <pre> public String check(){ s = ""; // 1. check connected modules for (Object o: evaluables) { String so=((IModule)o).check(); if (so.length > 0){ s += “checking connected module with ID “ + (IModule o).getID() + “ failed with message: \\n” + so; } } if (s.length > 0){ return “checking connected modules failed: \\n” + s; // 2. check this module, return String if not successful if (opt.verbose > 3) s+= "Option verbose must be between 0 and 3, but is set to " + opt.verbose + "\\n"; // … return s; } </pre> == Method <tt>String init(long index)</tt> == Currently the <tt>index</tt> is not used! # Functionality #* initialize <tt>Modules</tt> such that executing optimizations or learning processes is possible. #* Initialization requires several steps: #*# check if the argument (index) has changed compared to the time of the last check (see also example below). If the argument has not changed, the system has not changed and a new initialization is not necessary. Thus, return the message of the previous check and do no further checking. #*# If the <tt>Modules</tt> is connected to other Modules, it should first #*#* call the <tt>init()</tt> of the connected <tt>Modules</tt> and #*#* return a message, if any connected <tt>Modules</tt> fails to initialize #*# If the initialization of the connected <tt>Modules</tt> is successful, it should then get the properties of the connected <tt>Modules</tt> #*#* return a message, if any connected <tt>Modules</tt> fails to return properties. #*# Initialize itself and return a string if initialization fails. # Objectives #* initialization should never lead to exceptions. #* It must not call <tt>check()</tt>! # Properties #* the <tt>init()</tt> method is the only method of <tt>IModule</tt> that may require CPU time (e.g. for loading a large data source). Thus this method should not be called too often. # Advanced Features #* the<tt>Modules</tt> should check if initialization is necessary. Typically initialization is necessary when #** the <tt>Options</tt> of the<tt>Modules</tt> are changed #** the connections of the<tt>Modules</tt> changed #** the properties of the connected <i>Modules</i> changed #* if nothing changed, it should not initialize in order to save computer resources # Return Value #* empty string “” if successful, else a message # Sample Code for Optimization: <pre> public string init(long init_id){ s = ""; if (this.init_id == init_id){ return [the message of the last initialization]; this.init_id = init_id; for (Object o: evaluables) { String so=((IModule)o).init(init_id); if (so.length > 0){ s += “initializing connected module with ID “ + (IModule o).getID() + “ failed with message: \\n” + so; } } if (s.length > 0){ return “initializing connected modules failed: \\n” + s; // initialize this module, return String if not successful // … return s; } </pre> == Method <tt>int getID()</tt> == # Functionality #* gets the ID for this <tt>Module</tt>. # Objectives #* the ID is important for debugging, e.g. <tt>Modules</tt> can identify to which other <tt>Modules</tt> they are connected. == Method <tt>void setID(int id)</tt> == # Functionality #* sets the ID for this<tt>Modules</tt>. # Objectives #* IDs should be set at the time of instantiation and should not be modified. #* the ID is important for debugging, e.g. <i>Modules</i> can identify to which other <i>Modules</i> they are connected == Method <tt>String getInfo()</tt> == # Functionality #* Returns a String in HTML or plain text, describing the module #* A<tt>Modules</tt> such as an optimization algorithm should return the problem properties when it this<tt>Modules</tt> is called. # Objectives #* get information about<tt>Modules</tt> properties for checking or debugging user settings == Summary == # properties of a<tt>Modules</tt> should only change when the Method <tt>init()</tt> is called. #* this guarantees that <i>Modules</i> do not change while they are checked! = Open Items = * 'path handling for files','The path handling of openopal: files that are eg. written by the protocoller are placed in the source directory of the code. Instead the should be a working directory (e.g. the one where one calls openopal from). In addition, the file browsing dialog should remember the working directory (of the previous call).' * 'Thead save','Methods like evaluate() or init() are currently not thread save. Multiple (optimization) algorithms may call these methods. One solution to this is to synchronize critical methods. ','Methods like evaluate() or init() are currently not thread save. Multiple (optimization) algorithms may call these methods. 80 79 2013-03-18T20:35:09Z Dirk 2 /* Method void setID(int id) */ wikitext text/x-wiki =Interface <tt>IModule</tt>= All <tt>Modules</tt> in OpenOpal must implement the Interface <tt> IModule</tt>. The interface contains a set of methods. The purpose and the functionality of these methods is described in the following sections. Furthermore, the <tt>Modules</tt> must have a class <tt>Options</tt> that comprises all user settings as simple types (<tt>boolean</tt>, <tt>long</tt>, <tt>double</tt>, <tt>String</tt>) or vectors/arrays of those types. The options are automatically read using Java Reflection API. It is essential for a correct program execution to ensure that the guidelines are exactly followed by the <tt>Modules</tt> programmers. == Method <tt>Options getOptions()</tt> == # Functionality #* returns the current <tt>Options</tt> class. #* ensure that cloned <tt>Options</tt> are returned! # Objectives #* returning a clone of the <tt>Options</tt> ensures that changing <tt>Options</tt> outside the <tt>Module</tt> has no impact. # Sample Code <pre> public Options getOptions() { return (Options) options.clone(); } </pre> == Method <tt>void setOptions(Options o)</tt> == # Functionality #* sets the <tt>Options</tt> for a <tt>Module</tt> #* ensure that <tt>Options</tt> are cloned before they are set! # Objectives #* setting a clone of the <tt>Options</tt> ensures that changing <tt>Options</tt> outside the <tt>Modules</tt> has no impact. # Sample Code <pre> public void setOptions(Options o) { options = (Options) o.clone(); } </pre> == Method <tt>String check() </tt> == # Functionality #* check, if this <tt>Modules</tt> is set up correctly, i.e. checks if #** the <tt>Options</tt> are correct? #** all required <tt>Connections</tt> of the <tt>Modules</tt> are available (e.g. an optimization algorithm may require one connection to a problem) #** the settings (e.g. Options) agree with the properties of connected <tt>Modules</tt>? #* checking requires several steps: #*# if the <tt>Modules</tt> is connected to other <tt>Modules</tt>, it should first #*#* call <tt>check()</tt> of the connected <tt>Modules</tt> and #*#* return a message, if any connected <tt>Modules</tt>’s check is unsuccessful (i.e. a non-empty string is returned). #*# if checking the connected <tt>Modules</tt> was successful, the <tt>Modules</tt> should check itself and return a non-empty string if checking fails. # Properties #* checks are usually fast # Return Value #* empty string “” if successful, else a message #Sample Code for Optimization: <pre> public String check(){ s = ""; // 1. check connected modules for (Object o: evaluables) { String so=((IModule)o).check(); if (so.length > 0){ s += “checking connected module with ID “ + (IModule o).getID() + “ failed with message: \\n” + so; } } if (s.length > 0){ return “checking connected modules failed: \\n” + s; // 2. check this module, return String if not successful if (opt.verbose > 3) s+= "Option verbose must be between 0 and 3, but is set to " + opt.verbose + "\\n"; // … return s; } </pre> == Method <tt>String init(long index)</tt> == Currently the <tt>index</tt> is not used! # Functionality #* initialize <tt>Modules</tt> such that executing optimizations or learning processes is possible. #* Initialization requires several steps: #*# check if the argument (index) has changed compared to the time of the last check (see also example below). If the argument has not changed, the system has not changed and a new initialization is not necessary. Thus, return the message of the previous check and do no further checking. #*# If the <tt>Modules</tt> is connected to other Modules, it should first #*#* call the <tt>init()</tt> of the connected <tt>Modules</tt> and #*#* return a message, if any connected <tt>Modules</tt> fails to initialize #*# If the initialization of the connected <tt>Modules</tt> is successful, it should then get the properties of the connected <tt>Modules</tt> #*#* return a message, if any connected <tt>Modules</tt> fails to return properties. #*# Initialize itself and return a string if initialization fails. # Objectives #* initialization should never lead to exceptions. #* It must not call <tt>check()</tt>! # Properties #* the <tt>init()</tt> method is the only method of <tt>IModule</tt> that may require CPU time (e.g. for loading a large data source). Thus this method should not be called too often. # Advanced Features #* the<tt>Modules</tt> should check if initialization is necessary. Typically initialization is necessary when #** the <tt>Options</tt> of the<tt>Modules</tt> are changed #** the connections of the<tt>Modules</tt> changed #** the properties of the connected <i>Modules</i> changed #* if nothing changed, it should not initialize in order to save computer resources # Return Value #* empty string “” if successful, else a message # Sample Code for Optimization: <pre> public string init(long init_id){ s = ""; if (this.init_id == init_id){ return [the message of the last initialization]; this.init_id = init_id; for (Object o: evaluables) { String so=((IModule)o).init(init_id); if (so.length > 0){ s += “initializing connected module with ID “ + (IModule o).getID() + “ failed with message: \\n” + so; } } if (s.length > 0){ return “initializing connected modules failed: \\n” + s; // initialize this module, return String if not successful // … return s; } </pre> == Method <tt>int getID()</tt> == # Functionality #* gets the ID for this <tt>Module</tt>. # Objectives #* the ID is important for debugging, e.g. <tt>Modules</tt> can identify to which other <tt>Modules</tt> they are connected. == Method <tt>void setID(int id)</tt> == # Functionality #* sets the ID for this <tt>Module</tt>. # Objectives #* IDs should be set at the time of instantiation and should not be modified. #* the ID is important for debugging, e.g. <i>Modules</i> can identify to which other <i>Modules</i> they are connected == Method <tt>String getInfo()</tt> == # Functionality #* Returns a String in HTML or plain text, describing the module #* A<tt>Modules</tt> such as an optimization algorithm should return the problem properties when it this<tt>Modules</tt> is called. # Objectives #* get information about<tt>Modules</tt> properties for checking or debugging user settings == Summary == # properties of a<tt>Modules</tt> should only change when the Method <tt>init()</tt> is called. #* this guarantees that <i>Modules</i> do not change while they are checked! = Open Items = * 'path handling for files','The path handling of openopal: files that are eg. written by the protocoller are placed in the source directory of the code. Instead the should be a working directory (e.g. the one where one calls openopal from). In addition, the file browsing dialog should remember the working directory (of the previous call).' * 'Thead save','Methods like evaluate() or init() are currently not thread save. Multiple (optimization) algorithms may call these methods. One solution to this is to synchronize critical methods. ','Methods like evaluate() or init() are currently not thread save. Multiple (optimization) algorithms may call these methods. 81 80 2013-03-18T20:35:34Z Dirk 2 /* Method void setID(int id) */ wikitext text/x-wiki =Interface <tt>IModule</tt>= All <tt>Modules</tt> in OpenOpal must implement the Interface <tt> IModule</tt>. The interface contains a set of methods. The purpose and the functionality of these methods is described in the following sections. Furthermore, the <tt>Modules</tt> must have a class <tt>Options</tt> that comprises all user settings as simple types (<tt>boolean</tt>, <tt>long</tt>, <tt>double</tt>, <tt>String</tt>) or vectors/arrays of those types. The options are automatically read using Java Reflection API. It is essential for a correct program execution to ensure that the guidelines are exactly followed by the <tt>Modules</tt> programmers. == Method <tt>Options getOptions()</tt> == # Functionality #* returns the current <tt>Options</tt> class. #* ensure that cloned <tt>Options</tt> are returned! # Objectives #* returning a clone of the <tt>Options</tt> ensures that changing <tt>Options</tt> outside the <tt>Module</tt> has no impact. # Sample Code <pre> public Options getOptions() { return (Options) options.clone(); } </pre> == Method <tt>void setOptions(Options o)</tt> == # Functionality #* sets the <tt>Options</tt> for a <tt>Module</tt> #* ensure that <tt>Options</tt> are cloned before they are set! # Objectives #* setting a clone of the <tt>Options</tt> ensures that changing <tt>Options</tt> outside the <tt>Modules</tt> has no impact. # Sample Code <pre> public void setOptions(Options o) { options = (Options) o.clone(); } </pre> == Method <tt>String check() </tt> == # Functionality #* check, if this <tt>Modules</tt> is set up correctly, i.e. checks if #** the <tt>Options</tt> are correct? #** all required <tt>Connections</tt> of the <tt>Modules</tt> are available (e.g. an optimization algorithm may require one connection to a problem) #** the settings (e.g. Options) agree with the properties of connected <tt>Modules</tt>? #* checking requires several steps: #*# if the <tt>Modules</tt> is connected to other <tt>Modules</tt>, it should first #*#* call <tt>check()</tt> of the connected <tt>Modules</tt> and #*#* return a message, if any connected <tt>Modules</tt>’s check is unsuccessful (i.e. a non-empty string is returned). #*# if checking the connected <tt>Modules</tt> was successful, the <tt>Modules</tt> should check itself and return a non-empty string if checking fails. # Properties #* checks are usually fast # Return Value #* empty string “” if successful, else a message #Sample Code for Optimization: <pre> public String check(){ s = ""; // 1. check connected modules for (Object o: evaluables) { String so=((IModule)o).check(); if (so.length > 0){ s += “checking connected module with ID “ + (IModule o).getID() + “ failed with message: \\n” + so; } } if (s.length > 0){ return “checking connected modules failed: \\n” + s; // 2. check this module, return String if not successful if (opt.verbose > 3) s+= "Option verbose must be between 0 and 3, but is set to " + opt.verbose + "\\n"; // … return s; } </pre> == Method <tt>String init(long index)</tt> == Currently the <tt>index</tt> is not used! # Functionality #* initialize <tt>Modules</tt> such that executing optimizations or learning processes is possible. #* Initialization requires several steps: #*# check if the argument (index) has changed compared to the time of the last check (see also example below). If the argument has not changed, the system has not changed and a new initialization is not necessary. Thus, return the message of the previous check and do no further checking. #*# If the <tt>Modules</tt> is connected to other Modules, it should first #*#* call the <tt>init()</tt> of the connected <tt>Modules</tt> and #*#* return a message, if any connected <tt>Modules</tt> fails to initialize #*# If the initialization of the connected <tt>Modules</tt> is successful, it should then get the properties of the connected <tt>Modules</tt> #*#* return a message, if any connected <tt>Modules</tt> fails to return properties. #*# Initialize itself and return a string if initialization fails. # Objectives #* initialization should never lead to exceptions. #* It must not call <tt>check()</tt>! # Properties #* the <tt>init()</tt> method is the only method of <tt>IModule</tt> that may require CPU time (e.g. for loading a large data source). Thus this method should not be called too often. # Advanced Features #* the<tt>Modules</tt> should check if initialization is necessary. Typically initialization is necessary when #** the <tt>Options</tt> of the<tt>Modules</tt> are changed #** the connections of the<tt>Modules</tt> changed #** the properties of the connected <i>Modules</i> changed #* if nothing changed, it should not initialize in order to save computer resources # Return Value #* empty string “” if successful, else a message # Sample Code for Optimization: <pre> public string init(long init_id){ s = ""; if (this.init_id == init_id){ return [the message of the last initialization]; this.init_id = init_id; for (Object o: evaluables) { String so=((IModule)o).init(init_id); if (so.length > 0){ s += “initializing connected module with ID “ + (IModule o).getID() + “ failed with message: \\n” + so; } } if (s.length > 0){ return “initializing connected modules failed: \\n” + s; // initialize this module, return String if not successful // … return s; } </pre> == Method <tt>int getID()</tt> == # Functionality #* gets the ID for this <tt>Module</tt>. # Objectives #* the ID is important for debugging, e.g. <tt>Modules</tt> can identify to which other <tt>Modules</tt> they are connected. == Method <tt>void setID(int id)</tt> == # Functionality #* sets the ID for this <tt>Module</tt>. # Objectives #* IDs should be set at the time of instantiation and should not be modified. #* the ID is important for debugging, e.g. <tt>Modules</tt> can identify to which other <tt>Modules</tt> they are connected. == Method <tt>String getInfo()</tt> == # Functionality #* Returns a String in HTML or plain text, describing the module #* A<tt>Modules</tt> such as an optimization algorithm should return the problem properties when it this<tt>Modules</tt> is called. # Objectives #* get information about<tt>Modules</tt> properties for checking or debugging user settings == Summary == # properties of a<tt>Modules</tt> should only change when the Method <tt>init()</tt> is called. #* this guarantees that <i>Modules</i> do not change while they are checked! = Open Items = * 'path handling for files','The path handling of openopal: files that are eg. written by the protocoller are placed in the source directory of the code. Instead the should be a working directory (e.g. the one where one calls openopal from). In addition, the file browsing dialog should remember the working directory (of the previous call).' * 'Thead save','Methods like evaluate() or init() are currently not thread save. Multiple (optimization) algorithms may call these methods. One solution to this is to synchronize critical methods. ','Methods like evaluate() or init() are currently not thread save. Multiple (optimization) algorithms may call these methods. 82 81 2013-03-18T20:36:28Z Dirk 2 /* Summary */ wikitext text/x-wiki =Interface <tt>IModule</tt>= All <tt>Modules</tt> in OpenOpal must implement the Interface <tt> IModule</tt>. The interface contains a set of methods. The purpose and the functionality of these methods is described in the following sections. Furthermore, the <tt>Modules</tt> must have a class <tt>Options</tt> that comprises all user settings as simple types (<tt>boolean</tt>, <tt>long</tt>, <tt>double</tt>, <tt>String</tt>) or vectors/arrays of those types. The options are automatically read using Java Reflection API. It is essential for a correct program execution to ensure that the guidelines are exactly followed by the <tt>Modules</tt> programmers. == Method <tt>Options getOptions()</tt> == # Functionality #* returns the current <tt>Options</tt> class. #* ensure that cloned <tt>Options</tt> are returned! # Objectives #* returning a clone of the <tt>Options</tt> ensures that changing <tt>Options</tt> outside the <tt>Module</tt> has no impact. # Sample Code <pre> public Options getOptions() { return (Options) options.clone(); } </pre> == Method <tt>void setOptions(Options o)</tt> == # Functionality #* sets the <tt>Options</tt> for a <tt>Module</tt> #* ensure that <tt>Options</tt> are cloned before they are set! # Objectives #* setting a clone of the <tt>Options</tt> ensures that changing <tt>Options</tt> outside the <tt>Modules</tt> has no impact. # Sample Code <pre> public void setOptions(Options o) { options = (Options) o.clone(); } </pre> == Method <tt>String check() </tt> == # Functionality #* check, if this <tt>Modules</tt> is set up correctly, i.e. checks if #** the <tt>Options</tt> are correct? #** all required <tt>Connections</tt> of the <tt>Modules</tt> are available (e.g. an optimization algorithm may require one connection to a problem) #** the settings (e.g. Options) agree with the properties of connected <tt>Modules</tt>? #* checking requires several steps: #*# if the <tt>Modules</tt> is connected to other <tt>Modules</tt>, it should first #*#* call <tt>check()</tt> of the connected <tt>Modules</tt> and #*#* return a message, if any connected <tt>Modules</tt>’s check is unsuccessful (i.e. a non-empty string is returned). #*# if checking the connected <tt>Modules</tt> was successful, the <tt>Modules</tt> should check itself and return a non-empty string if checking fails. # Properties #* checks are usually fast # Return Value #* empty string “” if successful, else a message #Sample Code for Optimization: <pre> public String check(){ s = ""; // 1. check connected modules for (Object o: evaluables) { String so=((IModule)o).check(); if (so.length > 0){ s += “checking connected module with ID “ + (IModule o).getID() + “ failed with message: \\n” + so; } } if (s.length > 0){ return “checking connected modules failed: \\n” + s; // 2. check this module, return String if not successful if (opt.verbose > 3) s+= "Option verbose must be between 0 and 3, but is set to " + opt.verbose + "\\n"; // … return s; } </pre> == Method <tt>String init(long index)</tt> == Currently the <tt>index</tt> is not used! # Functionality #* initialize <tt>Modules</tt> such that executing optimizations or learning processes is possible. #* Initialization requires several steps: #*# check if the argument (index) has changed compared to the time of the last check (see also example below). If the argument has not changed, the system has not changed and a new initialization is not necessary. Thus, return the message of the previous check and do no further checking. #*# If the <tt>Modules</tt> is connected to other Modules, it should first #*#* call the <tt>init()</tt> of the connected <tt>Modules</tt> and #*#* return a message, if any connected <tt>Modules</tt> fails to initialize #*# If the initialization of the connected <tt>Modules</tt> is successful, it should then get the properties of the connected <tt>Modules</tt> #*#* return a message, if any connected <tt>Modules</tt> fails to return properties. #*# Initialize itself and return a string if initialization fails. # Objectives #* initialization should never lead to exceptions. #* It must not call <tt>check()</tt>! # Properties #* the <tt>init()</tt> method is the only method of <tt>IModule</tt> that may require CPU time (e.g. for loading a large data source). Thus this method should not be called too often. # Advanced Features #* the<tt>Modules</tt> should check if initialization is necessary. Typically initialization is necessary when #** the <tt>Options</tt> of the<tt>Modules</tt> are changed #** the connections of the<tt>Modules</tt> changed #** the properties of the connected <i>Modules</i> changed #* if nothing changed, it should not initialize in order to save computer resources # Return Value #* empty string “” if successful, else a message # Sample Code for Optimization: <pre> public string init(long init_id){ s = ""; if (this.init_id == init_id){ return [the message of the last initialization]; this.init_id = init_id; for (Object o: evaluables) { String so=((IModule)o).init(init_id); if (so.length > 0){ s += “initializing connected module with ID “ + (IModule o).getID() + “ failed with message: \\n” + so; } } if (s.length > 0){ return “initializing connected modules failed: \\n” + s; // initialize this module, return String if not successful // … return s; } </pre> == Method <tt>int getID()</tt> == # Functionality #* gets the ID for this <tt>Module</tt>. # Objectives #* the ID is important for debugging, e.g. <tt>Modules</tt> can identify to which other <tt>Modules</tt> they are connected. == Method <tt>void setID(int id)</tt> == # Functionality #* sets the ID for this <tt>Module</tt>. # Objectives #* IDs should be set at the time of instantiation and should not be modified. #* the ID is important for debugging, e.g. <tt>Modules</tt> can identify to which other <tt>Modules</tt> they are connected. == Method <tt>String getInfo()</tt> == # Functionality #* Returns a String in HTML or plain text, describing the module #* A<tt>Modules</tt> such as an optimization algorithm should return the problem properties when it this<tt>Modules</tt> is called. # Objectives #* get information about<tt>Modules</tt> properties for checking or debugging user settings == Summary == # properties of a <tt>Module</tt> should only change when the Method <tt>init()</tt> is called. #* this guarantees that <tt>Modules</tt> do not change while they are checked or other <tt>Modules</tt> are running! = Open Items = * 'path handling for files','The path handling of openopal: files that are eg. written by the protocoller are placed in the source directory of the code. Instead the should be a working directory (e.g. the one where one calls openopal from). In addition, the file browsing dialog should remember the working directory (of the previous call).' * 'Thead save','Methods like evaluate() or init() are currently not thread save. Multiple (optimization) algorithms may call these methods. One solution to this is to synchronize critical methods. ','Methods like evaluate() or init() are currently not thread save. Multiple (optimization) algorithms may call these methods. 83 82 2013-03-18T20:36:40Z Dirk 2 /* Summary */ wikitext text/x-wiki =Interface <tt>IModule</tt>= All <tt>Modules</tt> in OpenOpal must implement the Interface <tt> IModule</tt>. The interface contains a set of methods. The purpose and the functionality of these methods is described in the following sections. Furthermore, the <tt>Modules</tt> must have a class <tt>Options</tt> that comprises all user settings as simple types (<tt>boolean</tt>, <tt>long</tt>, <tt>double</tt>, <tt>String</tt>) or vectors/arrays of those types. The options are automatically read using Java Reflection API. It is essential for a correct program execution to ensure that the guidelines are exactly followed by the <tt>Modules</tt> programmers. == Method <tt>Options getOptions()</tt> == # Functionality #* returns the current <tt>Options</tt> class. #* ensure that cloned <tt>Options</tt> are returned! # Objectives #* returning a clone of the <tt>Options</tt> ensures that changing <tt>Options</tt> outside the <tt>Module</tt> has no impact. # Sample Code <pre> public Options getOptions() { return (Options) options.clone(); } </pre> == Method <tt>void setOptions(Options o)</tt> == # Functionality #* sets the <tt>Options</tt> for a <tt>Module</tt> #* ensure that <tt>Options</tt> are cloned before they are set! # Objectives #* setting a clone of the <tt>Options</tt> ensures that changing <tt>Options</tt> outside the <tt>Modules</tt> has no impact. # Sample Code <pre> public void setOptions(Options o) { options = (Options) o.clone(); } </pre> == Method <tt>String check() </tt> == # Functionality #* check, if this <tt>Modules</tt> is set up correctly, i.e. checks if #** the <tt>Options</tt> are correct? #** all required <tt>Connections</tt> of the <tt>Modules</tt> are available (e.g. an optimization algorithm may require one connection to a problem) #** the settings (e.g. Options) agree with the properties of connected <tt>Modules</tt>? #* checking requires several steps: #*# if the <tt>Modules</tt> is connected to other <tt>Modules</tt>, it should first #*#* call <tt>check()</tt> of the connected <tt>Modules</tt> and #*#* return a message, if any connected <tt>Modules</tt>’s check is unsuccessful (i.e. a non-empty string is returned). #*# if checking the connected <tt>Modules</tt> was successful, the <tt>Modules</tt> should check itself and return a non-empty string if checking fails. # Properties #* checks are usually fast # Return Value #* empty string “” if successful, else a message #Sample Code for Optimization: <pre> public String check(){ s = ""; // 1. check connected modules for (Object o: evaluables) { String so=((IModule)o).check(); if (so.length > 0){ s += “checking connected module with ID “ + (IModule o).getID() + “ failed with message: \\n” + so; } } if (s.length > 0){ return “checking connected modules failed: \\n” + s; // 2. check this module, return String if not successful if (opt.verbose > 3) s+= "Option verbose must be between 0 and 3, but is set to " + opt.verbose + "\\n"; // … return s; } </pre> == Method <tt>String init(long index)</tt> == Currently the <tt>index</tt> is not used! # Functionality #* initialize <tt>Modules</tt> such that executing optimizations or learning processes is possible. #* Initialization requires several steps: #*# check if the argument (index) has changed compared to the time of the last check (see also example below). If the argument has not changed, the system has not changed and a new initialization is not necessary. Thus, return the message of the previous check and do no further checking. #*# If the <tt>Modules</tt> is connected to other Modules, it should first #*#* call the <tt>init()</tt> of the connected <tt>Modules</tt> and #*#* return a message, if any connected <tt>Modules</tt> fails to initialize #*# If the initialization of the connected <tt>Modules</tt> is successful, it should then get the properties of the connected <tt>Modules</tt> #*#* return a message, if any connected <tt>Modules</tt> fails to return properties. #*# Initialize itself and return a string if initialization fails. # Objectives #* initialization should never lead to exceptions. #* It must not call <tt>check()</tt>! # Properties #* the <tt>init()</tt> method is the only method of <tt>IModule</tt> that may require CPU time (e.g. for loading a large data source). Thus this method should not be called too often. # Advanced Features #* the<tt>Modules</tt> should check if initialization is necessary. Typically initialization is necessary when #** the <tt>Options</tt> of the<tt>Modules</tt> are changed #** the connections of the<tt>Modules</tt> changed #** the properties of the connected <i>Modules</i> changed #* if nothing changed, it should not initialize in order to save computer resources # Return Value #* empty string “” if successful, else a message # Sample Code for Optimization: <pre> public string init(long init_id){ s = ""; if (this.init_id == init_id){ return [the message of the last initialization]; this.init_id = init_id; for (Object o: evaluables) { String so=((IModule)o).init(init_id); if (so.length > 0){ s += “initializing connected module with ID “ + (IModule o).getID() + “ failed with message: \\n” + so; } } if (s.length > 0){ return “initializing connected modules failed: \\n” + s; // initialize this module, return String if not successful // … return s; } </pre> == Method <tt>int getID()</tt> == # Functionality #* gets the ID for this <tt>Module</tt>. # Objectives #* the ID is important for debugging, e.g. <tt>Modules</tt> can identify to which other <tt>Modules</tt> they are connected. == Method <tt>void setID(int id)</tt> == # Functionality #* sets the ID for this <tt>Module</tt>. # Objectives #* IDs should be set at the time of instantiation and should not be modified. #* the ID is important for debugging, e.g. <tt>Modules</tt> can identify to which other <tt>Modules</tt> they are connected. == Method <tt>String getInfo()</tt> == # Functionality #* Returns a String in HTML or plain text, describing the module #* A<tt>Modules</tt> such as an optimization algorithm should return the problem properties when it this<tt>Modules</tt> is called. # Objectives #* get information about<tt>Modules</tt> properties for checking or debugging user settings = Open Items = * 'path handling for files','The path handling of openopal: files that are eg. written by the protocoller are placed in the source directory of the code. Instead the should be a working directory (e.g. the one where one calls openopal from). In addition, the file browsing dialog should remember the working directory (of the previous call).' * 'Thead save','Methods like evaluate() or init() are currently not thread save. Multiple (optimization) algorithms may call these methods. One solution to this is to synchronize critical methods. ','Methods like evaluate() or init() are currently not thread save. Multiple (optimization) algorithms may call these methods. 84 83 2013-03-18T20:37:53Z Dirk 2 /* Method String init(long index) */ wikitext text/x-wiki =Interface <tt>IModule</tt>= All <tt>Modules</tt> in OpenOpal must implement the Interface <tt> IModule</tt>. The interface contains a set of methods. The purpose and the functionality of these methods is described in the following sections. Furthermore, the <tt>Modules</tt> must have a class <tt>Options</tt> that comprises all user settings as simple types (<tt>boolean</tt>, <tt>long</tt>, <tt>double</tt>, <tt>String</tt>) or vectors/arrays of those types. The options are automatically read using Java Reflection API. It is essential for a correct program execution to ensure that the guidelines are exactly followed by the <tt>Modules</tt> programmers. == Method <tt>Options getOptions()</tt> == # Functionality #* returns the current <tt>Options</tt> class. #* ensure that cloned <tt>Options</tt> are returned! # Objectives #* returning a clone of the <tt>Options</tt> ensures that changing <tt>Options</tt> outside the <tt>Module</tt> has no impact. # Sample Code <pre> public Options getOptions() { return (Options) options.clone(); } </pre> == Method <tt>void setOptions(Options o)</tt> == # Functionality #* sets the <tt>Options</tt> for a <tt>Module</tt> #* ensure that <tt>Options</tt> are cloned before they are set! # Objectives #* setting a clone of the <tt>Options</tt> ensures that changing <tt>Options</tt> outside the <tt>Modules</tt> has no impact. # Sample Code <pre> public void setOptions(Options o) { options = (Options) o.clone(); } </pre> == Method <tt>String check() </tt> == # Functionality #* check, if this <tt>Modules</tt> is set up correctly, i.e. checks if #** the <tt>Options</tt> are correct? #** all required <tt>Connections</tt> of the <tt>Modules</tt> are available (e.g. an optimization algorithm may require one connection to a problem) #** the settings (e.g. Options) agree with the properties of connected <tt>Modules</tt>? #* checking requires several steps: #*# if the <tt>Modules</tt> is connected to other <tt>Modules</tt>, it should first #*#* call <tt>check()</tt> of the connected <tt>Modules</tt> and #*#* return a message, if any connected <tt>Modules</tt>’s check is unsuccessful (i.e. a non-empty string is returned). #*# if checking the connected <tt>Modules</tt> was successful, the <tt>Modules</tt> should check itself and return a non-empty string if checking fails. # Properties #* checks are usually fast # Return Value #* empty string “” if successful, else a message #Sample Code for Optimization: <pre> public String check(){ s = ""; // 1. check connected modules for (Object o: evaluables) { String so=((IModule)o).check(); if (so.length > 0){ s += “checking connected module with ID “ + (IModule o).getID() + “ failed with message: \\n” + so; } } if (s.length > 0){ return “checking connected modules failed: \\n” + s; // 2. check this module, return String if not successful if (opt.verbose > 3) s+= "Option verbose must be between 0 and 3, but is set to " + opt.verbose + "\\n"; // … return s; } </pre> == Method <tt>String init(long index)</tt> == Currently the <tt>index</tt> is not used! # Functionality #* initialize <tt>Modules</tt> such that executing optimizations or learning processes is possible. #* Initialization requires several steps: #*# check if the argument (index) has changed compared to the time of the last check (see also example below). If the argument has not changed, the system has not changed and a new initialization is not necessary. Thus, return the message of the previous check and do no further checking. #*# If the <tt>Modules</tt> is connected to other Modules, it should first #*#* call the <tt>init()</tt> of the connected <tt>Modules</tt> and #*#* return a message, if any connected <tt>Modules</tt> fails to initialize #*# If the initialization of the connected <tt>Modules</tt> is successful, it should then get the properties of the connected <tt>Modules</tt> #*#* return a message, if any connected <tt>Modules</tt> fails to return properties. #*# Initialize itself and return a string if initialization fails. # Objectives #* initialization should never lead to exceptions. #* It must not call <tt>check()</tt>! # Properties #* the <tt>init()</tt> method is the only method of <tt>IModule</tt> that may require CPU time (e.g. for loading a large data source). Thus this method should not be called too often. # Advanced Features #* the<tt>Modules</tt> should check if initialization is necessary. Typically initialization is necessary when #** the <tt>Options</tt> of the<tt>Modules</tt> are changed #** the connections of the<tt>Modules</tt> changed #** the properties of the connected <i>Modules</i> changed #* if nothing changed, it should not initialize in order to save computer resources # Return Value #* empty string “” if successful, else a message # Sample Code for Optimization: <pre> public string init(long init_id){ s = ""; if (this.init_id == init_id){ return [the message of the last initialization]; this.init_id = init_id; for (Object o: evaluables) { String so=((IModule)o).init(init_id); if (so.length > 0){ s += “initializing connected module with ID “ + (IModule o).getID() + “ failed with message: \\n” + so; } } if (s.length > 0){ return “initializing connected modules failed: \\n” + s; // initialize this module, return String if not successful // … return s; } </pre> '''Summary''' Properties of a <tt>Module</tt> should only change when the Method <tt>init()</tt> is called. This guarantees that <tt>Modules</tt> do not change while they are checked or other <tt>Modules</tt> are running! == Method <tt>int getID()</tt> == # Functionality #* gets the ID for this <tt>Module</tt>. # Objectives #* the ID is important for debugging, e.g. <tt>Modules</tt> can identify to which other <tt>Modules</tt> they are connected. == Method <tt>void setID(int id)</tt> == # Functionality #* sets the ID for this <tt>Module</tt>. # Objectives #* IDs should be set at the time of instantiation and should not be modified. #* the ID is important for debugging, e.g. <tt>Modules</tt> can identify to which other <tt>Modules</tt> they are connected. == Method <tt>String getInfo()</tt> == # Functionality #* Returns a String in HTML or plain text, describing the module #* A<tt>Modules</tt> such as an optimization algorithm should return the problem properties when it this<tt>Modules</tt> is called. # Objectives #* get information about<tt>Modules</tt> properties for checking or debugging user settings = Open Items = * 'path handling for files','The path handling of openopal: files that are eg. written by the protocoller are placed in the source directory of the code. Instead the should be a working directory (e.g. the one where one calls openopal from). In addition, the file browsing dialog should remember the working directory (of the previous call).' * 'Thead save','Methods like evaluate() or init() are currently not thread save. Multiple (optimization) algorithms may call these methods. One solution to this is to synchronize critical methods. ','Methods like evaluate() or init() are currently not thread save. Multiple (optimization) algorithms may call these methods. 85 84 2013-03-18T20:38:20Z Dirk 2 /* Open Items */ wikitext text/x-wiki =Interface <tt>IModule</tt>= All <tt>Modules</tt> in OpenOpal must implement the Interface <tt> IModule</tt>. The interface contains a set of methods. The purpose and the functionality of these methods is described in the following sections. Furthermore, the <tt>Modules</tt> must have a class <tt>Options</tt> that comprises all user settings as simple types (<tt>boolean</tt>, <tt>long</tt>, <tt>double</tt>, <tt>String</tt>) or vectors/arrays of those types. The options are automatically read using Java Reflection API. It is essential for a correct program execution to ensure that the guidelines are exactly followed by the <tt>Modules</tt> programmers. == Method <tt>Options getOptions()</tt> == # Functionality #* returns the current <tt>Options</tt> class. #* ensure that cloned <tt>Options</tt> are returned! # Objectives #* returning a clone of the <tt>Options</tt> ensures that changing <tt>Options</tt> outside the <tt>Module</tt> has no impact. # Sample Code <pre> public Options getOptions() { return (Options) options.clone(); } </pre> == Method <tt>void setOptions(Options o)</tt> == # Functionality #* sets the <tt>Options</tt> for a <tt>Module</tt> #* ensure that <tt>Options</tt> are cloned before they are set! # Objectives #* setting a clone of the <tt>Options</tt> ensures that changing <tt>Options</tt> outside the <tt>Modules</tt> has no impact. # Sample Code <pre> public void setOptions(Options o) { options = (Options) o.clone(); } </pre> == Method <tt>String check() </tt> == # Functionality #* check, if this <tt>Modules</tt> is set up correctly, i.e. checks if #** the <tt>Options</tt> are correct? #** all required <tt>Connections</tt> of the <tt>Modules</tt> are available (e.g. an optimization algorithm may require one connection to a problem) #** the settings (e.g. Options) agree with the properties of connected <tt>Modules</tt>? #* checking requires several steps: #*# if the <tt>Modules</tt> is connected to other <tt>Modules</tt>, it should first #*#* call <tt>check()</tt> of the connected <tt>Modules</tt> and #*#* return a message, if any connected <tt>Modules</tt>’s check is unsuccessful (i.e. a non-empty string is returned). #*# if checking the connected <tt>Modules</tt> was successful, the <tt>Modules</tt> should check itself and return a non-empty string if checking fails. # Properties #* checks are usually fast # Return Value #* empty string “” if successful, else a message #Sample Code for Optimization: <pre> public String check(){ s = ""; // 1. check connected modules for (Object o: evaluables) { String so=((IModule)o).check(); if (so.length > 0){ s += “checking connected module with ID “ + (IModule o).getID() + “ failed with message: \\n” + so; } } if (s.length > 0){ return “checking connected modules failed: \\n” + s; // 2. check this module, return String if not successful if (opt.verbose > 3) s+= "Option verbose must be between 0 and 3, but is set to " + opt.verbose + "\\n"; // … return s; } </pre> == Method <tt>String init(long index)</tt> == Currently the <tt>index</tt> is not used! # Functionality #* initialize <tt>Modules</tt> such that executing optimizations or learning processes is possible. #* Initialization requires several steps: #*# check if the argument (index) has changed compared to the time of the last check (see also example below). If the argument has not changed, the system has not changed and a new initialization is not necessary. Thus, return the message of the previous check and do no further checking. #*# If the <tt>Modules</tt> is connected to other Modules, it should first #*#* call the <tt>init()</tt> of the connected <tt>Modules</tt> and #*#* return a message, if any connected <tt>Modules</tt> fails to initialize #*# If the initialization of the connected <tt>Modules</tt> is successful, it should then get the properties of the connected <tt>Modules</tt> #*#* return a message, if any connected <tt>Modules</tt> fails to return properties. #*# Initialize itself and return a string if initialization fails. # Objectives #* initialization should never lead to exceptions. #* It must not call <tt>check()</tt>! # Properties #* the <tt>init()</tt> method is the only method of <tt>IModule</tt> that may require CPU time (e.g. for loading a large data source). Thus this method should not be called too often. # Advanced Features #* the<tt>Modules</tt> should check if initialization is necessary. Typically initialization is necessary when #** the <tt>Options</tt> of the<tt>Modules</tt> are changed #** the connections of the<tt>Modules</tt> changed #** the properties of the connected <i>Modules</i> changed #* if nothing changed, it should not initialize in order to save computer resources # Return Value #* empty string “” if successful, else a message # Sample Code for Optimization: <pre> public string init(long init_id){ s = ""; if (this.init_id == init_id){ return [the message of the last initialization]; this.init_id = init_id; for (Object o: evaluables) { String so=((IModule)o).init(init_id); if (so.length > 0){ s += “initializing connected module with ID “ + (IModule o).getID() + “ failed with message: \\n” + so; } } if (s.length > 0){ return “initializing connected modules failed: \\n” + s; // initialize this module, return String if not successful // … return s; } </pre> '''Summary''' Properties of a <tt>Module</tt> should only change when the Method <tt>init()</tt> is called. This guarantees that <tt>Modules</tt> do not change while they are checked or other <tt>Modules</tt> are running! == Method <tt>int getID()</tt> == # Functionality #* gets the ID for this <tt>Module</tt>. # Objectives #* the ID is important for debugging, e.g. <tt>Modules</tt> can identify to which other <tt>Modules</tt> they are connected. == Method <tt>void setID(int id)</tt> == # Functionality #* sets the ID for this <tt>Module</tt>. # Objectives #* IDs should be set at the time of instantiation and should not be modified. #* the ID is important for debugging, e.g. <tt>Modules</tt> can identify to which other <tt>Modules</tt> they are connected. == Method <tt>String getInfo()</tt> == # Functionality #* Returns a String in HTML or plain text, describing the module #* A<tt>Modules</tt> such as an optimization algorithm should return the problem properties when it this<tt>Modules</tt> is called. # Objectives #* get information about<tt>Modules</tt> properties for checking or debugging user settings 0 37 86 2013-03-18T20:39:33Z Dirk 2 Created page with "== Thead Save == 'Thead save','Methods like evaluate() or init() are currently not thread save. Multiple (optimization) algorithms may call these methods. One solution to this i..." wikitext text/x-wiki == Thead Save == 'Thead save','Methods like evaluate() or init() are currently not thread save. Multiple (optimization) algorithms may call these methods. One solution to this is to synchronize critical methods. ','Methods like evaluate() or init() are currently not thread save. Multiple (optimization) algorithms may call these methods. 0 38 88 2013-03-18T20:44:31Z Dirk 2 Created page with "==Basics== The basic element of each OpenOpal optimization or learning environment is still the <code>Module</code>. Each optimization problem, each optimization algorithm and e..." wikitext text/x-wiki ==Basics== The basic element of each OpenOpal optimization or learning environment is still the <code>Module</code>. Each optimization problem, each optimization algorithm and each learning algorithm is a module. A class that is used as a module must implement the interface <code>org.openopal.core.modules.IModule</code> (see [Documentation/IModule IModule]). The whole structure of modules in OpenOpal is based on interfaces. The reason for this is that classes that are used as modules may be part of a class hierarchy and thus they cannot inherit from a basic module class. There are modules that can be run, e.g. optimization algorithms. All these modules implement the interface org.openopal.core.modules.IRunnable. Each optimization setup consists of at least two linked modules: a problem and an optimizer. The interfaces for these modules are org.openopal.core.modules.optimization.IEvaluable and IEvaluator, respecively. The corresponding pair for a learning task is org.openopal.core.modules.learning.IDataSource and IDataSink. Modules can be linked between other modules. E.g. the protocoller is a module that you can link between an optimizer and a problem. In such a case, all modules except the optimizer must implement the interface IEvaluable and all modules except the problem must implement the interface IEvaluator. This means that the modules form a chain that looks like this (here, two intermediate modules are shown): <pre> IEvaluator | IEvaluable and IEvaluator | IEvaluable and IEvaluator | IEvaluable </pre> where the topmost evaluator is the optimizer and the bottommost evaluable is the optimization problem. The meaning of this picure is that the optimizer produces points and sends them through the chain to the problem. The problem evaluates the points, assinging each point its objective value(s). These are read by the optimizer which then tries to create better points, etc. The same kind of interaction chain is possible for learners and data sources. But there, the information flow is mainly in unidirectional: from the data source to the data sink. The class that represents solutions to optimization problems is Solution. Every instance of this class is a solution to the optimization problem. Each Solution object contains the design variables that define the solution and one or more objective values that assess the quality of the solution. The goal of each optimization algorithm is to find a Solution with minimal objective values. An object of the class Data represents the data involved in a particular learning setup. It is passed from data source to data sink. Often, modules look similar, and someone writing a new module doens't want to implement all interface methods by hand. For these cases, we wrote the abstract classes org.openopal.core.modules.optimization.Optimizer and Problem and learning.Learner. These classes already implement almost all necessary methods. A writer of an optimizer just has to implement the algorithm itself and no other details (e.g. linking, checking etc.). Similarly, a writer of a problem just has to implement the evaluate method of the Problem class. In a learner, the method to override is run(). It executes the learning algorithm. ==Documentation and Contracts== (Almost) each interface, class and method has a JavaDoc comment that defines its documentation. The documentation of methods consists of descriptions of the purpose, the parameters and the return value. We provided many methods with contracts. These are also described on the page https://www.openopal.org/wiki/index.php/Documentation:Contracts. It is important to know these contracts when using (or modifying) methods. Invariants can only be guaranteed if they are established by each constructor and not violated by any method. It should be impossible to access members of an object from outside the object without using a method of the object. That's why members that are part of invariants have to be cloned when they enter or leave the object. ==The Interfaces== ===IModule=== This is the basic interface implemented by all modules. It contains methods for the initialisation and checking of the module and for the management of the options of the module. ===IRunnable=== This interfaces is implemented by all modules that can be run. When a module is run, it executes its optimization algorithm. In the future this could be any kind of algorithm. The interface contains methods to start and stop the execution of the module. ===IEvaluable=== Every module that represents an optimization problem implements the interface IEvaluable. This means that the module can evaluate a given solution. To that end, it looks at the design variables of a solution object it gets from an optimizer and sets the objective value(s) of that object accordingly. If a module is linked before a problem module, it must implement IEvaluable and delegate the evaluation of the solutions to the problem module. Thus, the optmimizer doesn't know if the module right after it is the problem itself or an intermediate module, it just calls the evaluate method of its successor module. IEvaluable contains methods to evaluate one solution or an array of solutions and a method to get the properties of the problem. ===IEvaluator=== A module that can call an evaluable to evaluate solutions implements the interface IEvaluator. Normally, an evaluator is an optimizer module, but any intermediate module between the optimizer and the problem must implement this interface as well. Otherwise, it wouldn't be able to call the problem to evaluate the solutions. IEvaluator contains methods to get and set the references to the evaluables and to check if these links are OK. ===IDataSource=== A module that provides data. This can be a file reader, the protocoller, or other modules that can produce or store data. The getData() method is the most important one. ===IDataSink=== A module implementing this interface represents a learner. It is linked with a data source and processes the given data. Very different kinds of processing are possible. A data viewer can just display the data, a neural network can learn a function from the data or a statistics module can compute some statistics on the data etc. 89 88 2013-03-18T20:51:34Z Dirk 2 /* Basics */ wikitext text/x-wiki ==Basics== The basic element of each OpenOpal optimization or learning environment is still the <code>Module</code>. Each optimization problem, each optimization algorithm and each learning algorithm is a module. A class that is used as a module must implement the interface <code>org.openopal.core.modules.IModule</code> (see [[Documentation/IModule | IModule]]). The whole structure of modules in OpenOpal is based on interfaces. The reason for this is that classes that are used as <code>Modules</code> may be part of a class hierarchy and thus they cannot inherit from a basic module class. There are <code>Modules</code> that can be run, e.g. optimization algorithms. All these modules implement the interface <code>org.openopal.core.modules.IRunnable</code>. Each optimization setup consists of at least two linked <code>Modules</code>: a problem and an optimizer. The interfaces for these modules are <code>org.openopal.core.modules.optimization.IEvaluable</code> and <code>IEvaluator</code>, respecively. The corresponding pair for a learning task is <code>org.openopal.core.modules.learning.IDataSource</code> and <code>IDataSink</code>. Modules can be linked between other modules. E.g. the protocoller is a <code>Module</code> that you can link between an optimizer and a problem. In such a case, all <code>Modules</code> except the optimizer must implement the interface <code>Evaluable</code> and all modules except the problem must implement the interface <code>IEvaluator</code>. This means that the modules form a chain that looks like this (here, two intermediate modules are shown): <pre> [IEvaluator] | [IEvaluable and IEvaluator] | [IEvaluable and IEvaluator] | [IEvaluable] </pre> where the topmost evaluator is the optimizer and the bottommost evaluable is the optimization problem. The meaning of this picture is that the optimizer produces points and sends them through the chain to the problem. The problem evaluates the points, assigning each point its objective value(s). These are read by the optimizer which then tries to create better points, etc. The same kind of interaction chain is possible for learners and data sources. But there, the information flow is mainly in unidirectional: from the data source to the data sink. The class that represents solutions to optimization problems is <code>Solution</code>. Every instance of this class is a solution to the optimization problem. Each Solution object contains the design variables that define the solution and one or more objective values that assess the quality of the solution. The goal of each optimization algorithm is to find a Solution with minimal objective values. An object of the class Data represents the data involved in a particular learning setup. It is passed from data source to data sink. Often, modules look similar, and someone writing a new module doesn't want to implement all interface methods by hand. For these cases, we wrote the abstract classes <code>org.openopal.core.modules.optimization.Optimizer</code> and Problem and <code>learning.Learner</code>. These classes already implement almost all necessary methods. A writer of an optimizer just has to implement the algorithm itself and no other details (e.g. linking, checking etc.). Similarly, a writer of a problem just has to implement the evaluate method of the <code>Problem</code> class. In a learner, the method to override is run(). It executes the learning algorithm. ==Documentation and Contracts== (Almost) each interface, class and method has a JavaDoc comment that defines its documentation. The documentation of methods consists of descriptions of the purpose, the parameters and the return value. We provided many methods with contracts. These are also described on the page https://www.openopal.org/wiki/index.php/Documentation:Contracts. It is important to know these contracts when using (or modifying) methods. Invariants can only be guaranteed if they are established by each constructor and not violated by any method. It should be impossible to access members of an object from outside the object without using a method of the object. That's why members that are part of invariants have to be cloned when they enter or leave the object. ==The Interfaces== ===IModule=== This is the basic interface implemented by all modules. It contains methods for the initialisation and checking of the module and for the management of the options of the module. ===IRunnable=== This interfaces is implemented by all modules that can be run. When a module is run, it executes its optimization algorithm. In the future this could be any kind of algorithm. The interface contains methods to start and stop the execution of the module. ===IEvaluable=== Every module that represents an optimization problem implements the interface IEvaluable. This means that the module can evaluate a given solution. To that end, it looks at the design variables of a solution object it gets from an optimizer and sets the objective value(s) of that object accordingly. If a module is linked before a problem module, it must implement IEvaluable and delegate the evaluation of the solutions to the problem module. Thus, the optmimizer doesn't know if the module right after it is the problem itself or an intermediate module, it just calls the evaluate method of its successor module. IEvaluable contains methods to evaluate one solution or an array of solutions and a method to get the properties of the problem. ===IEvaluator=== A module that can call an evaluable to evaluate solutions implements the interface IEvaluator. Normally, an evaluator is an optimizer module, but any intermediate module between the optimizer and the problem must implement this interface as well. Otherwise, it wouldn't be able to call the problem to evaluate the solutions. IEvaluator contains methods to get and set the references to the evaluables and to check if these links are OK. ===IDataSource=== A module that provides data. This can be a file reader, the protocoller, or other modules that can produce or store data. The getData() method is the most important one. ===IDataSink=== A module implementing this interface represents a learner. It is linked with a data source and processes the given data. Very different kinds of processing are possible. A data viewer can just display the data, a neural network can learn a function from the data or a statistics module can compute some statistics on the data etc. 90 89 2013-03-18T20:55:30Z Dirk 2 /* Basics */ wikitext text/x-wiki ==Basics== The basic element of each OpenOpal optimization or learning environment is still the <code>Module</code>. Each optimization problem, each optimization algorithm and each learning algorithm is a module. A class that is used as a module must implement the interface <code>org.openopal.core.modules.IModule</code> (see [[Documentation/IModule | IModule]]). The whole structure of modules in OpenOpal is based on interfaces. The reason for this is that classes that are used as <code>Modules</code> may be part of a class hierarchy and thus they cannot inherit from a basic module class. There are <code>Modules</code> that can be run, e.g. optimization algorithms. All these modules implement the interface <code>org.openopal.core.modules.IRunnable</code>. Each optimization setup consists of at least two linked <code>Modules</code>: a problem and an optimizer. The interfaces for these modules are <code>org.openopal.core.modules.optimization.IEvaluable</code> and <code>IEvaluator</code>, respecively. The corresponding pair for a learning task is <code>org.openopal.core.modules.learning.IDataSource</code> and <code>IDataSink</code>. Modules can be linked between other modules. E.g. the protocoller is a <code>Module</code> that you can link between an optimizer and a problem. In such a case, all <code>Modules</code> except the optimizer must implement the interface <code>Evaluable</code> and all modules except the problem must implement the interface <code>IEvaluator</code>. This means that the modules form a chain that looks like this (here, two intermediate modules are shown): <pre> [IEvaluator] | [IEvaluable and IEvaluator] | [IEvaluable and IEvaluator] | [IEvaluable] </pre> where the topmost evaluator is the optimizer and the bottommost evaluable is the optimization problem. The meaning of this picture is that the optimizer produces points and sends them through the chain to the problem. The problem evaluates the points, assigning each point its objective value(s). These are read by the optimizer which then tries to create better points, etc. The same kind of interaction chain is possible for learners and data sources. But there, the information flow is mainly in unidirectional: from the data source to the data sink. The class that represents solutions to optimization problems is <code>Solution</code>. Every instance of this class is a solution to the optimization problem. Each <code>Solution</code> object contains the design variables that define the solution and one or more objective values that assess the quality of the solution. The goal of each optimization algorithm is to find a <code>Solution</code> with minimal objective values. An object of the class <code>Data</code> represents the data involved in a particular learning setup. It is passed from data source to data sink. Often, <code>Modules</code> look similar, and someone writing a new <code>Module</code> doesn't want to implement all interface methods by hand. For these cases, we wrote the abstract classes <code>org.openopal.core.modules.optimization.Optimizer</code> and <code>Problem</code> and <code>learning.Learner</code>. These classes already implement almost all necessary methods. A writer of an optimizer just has to implement the algorithm itself and no other details (e.g. linking, checking etc.). Similarly, a writer of a problem just has to implement the evaluate method of the <code>Problem</code> class. In a learner, the method to override is run(). It executes the learning algorithm. ==Documentation and Contracts== (Almost) each interface, class and method has a JavaDoc comment that defines its documentation. The documentation of methods consists of descriptions of the purpose, the parameters and the return value. We provided many methods with contracts. These are also described on the page https://www.openopal.org/wiki/index.php/Documentation:Contracts. It is important to know these contracts when using (or modifying) methods. Invariants can only be guaranteed if they are established by each constructor and not violated by any method. It should be impossible to access members of an object from outside the object without using a method of the object. That's why members that are part of invariants have to be cloned when they enter or leave the object. ==The Interfaces== ===IModule=== This is the basic interface implemented by all modules. It contains methods for the initialisation and checking of the module and for the management of the options of the module. ===IRunnable=== This interfaces is implemented by all modules that can be run. When a module is run, it executes its optimization algorithm. In the future this could be any kind of algorithm. The interface contains methods to start and stop the execution of the module. ===IEvaluable=== Every module that represents an optimization problem implements the interface IEvaluable. This means that the module can evaluate a given solution. To that end, it looks at the design variables of a solution object it gets from an optimizer and sets the objective value(s) of that object accordingly. If a module is linked before a problem module, it must implement IEvaluable and delegate the evaluation of the solutions to the problem module. Thus, the optmimizer doesn't know if the module right after it is the problem itself or an intermediate module, it just calls the evaluate method of its successor module. IEvaluable contains methods to evaluate one solution or an array of solutions and a method to get the properties of the problem. ===IEvaluator=== A module that can call an evaluable to evaluate solutions implements the interface IEvaluator. Normally, an evaluator is an optimizer module, but any intermediate module between the optimizer and the problem must implement this interface as well. Otherwise, it wouldn't be able to call the problem to evaluate the solutions. IEvaluator contains methods to get and set the references to the evaluables and to check if these links are OK. ===IDataSource=== A module that provides data. This can be a file reader, the protocoller, or other modules that can produce or store data. The getData() method is the most important one. ===IDataSink=== A module implementing this interface represents a learner. It is linked with a data source and processes the given data. Very different kinds of processing are possible. A data viewer can just display the data, a neural network can learn a function from the data or a statistics module can compute some statistics on the data etc. 91 90 2013-03-18T20:56:52Z Dirk 2 /* Documentation and Contracts */ wikitext text/x-wiki ==Basics== The basic element of each OpenOpal optimization or learning environment is still the <code>Module</code>. Each optimization problem, each optimization algorithm and each learning algorithm is a module. A class that is used as a module must implement the interface <code>org.openopal.core.modules.IModule</code> (see [[Documentation/IModule | IModule]]). The whole structure of modules in OpenOpal is based on interfaces. The reason for this is that classes that are used as <code>Modules</code> may be part of a class hierarchy and thus they cannot inherit from a basic module class. There are <code>Modules</code> that can be run, e.g. optimization algorithms. All these modules implement the interface <code>org.openopal.core.modules.IRunnable</code>. Each optimization setup consists of at least two linked <code>Modules</code>: a problem and an optimizer. The interfaces for these modules are <code>org.openopal.core.modules.optimization.IEvaluable</code> and <code>IEvaluator</code>, respecively. The corresponding pair for a learning task is <code>org.openopal.core.modules.learning.IDataSource</code> and <code>IDataSink</code>. Modules can be linked between other modules. E.g. the protocoller is a <code>Module</code> that you can link between an optimizer and a problem. In such a case, all <code>Modules</code> except the optimizer must implement the interface <code>Evaluable</code> and all modules except the problem must implement the interface <code>IEvaluator</code>. This means that the modules form a chain that looks like this (here, two intermediate modules are shown): <pre> [IEvaluator] | [IEvaluable and IEvaluator] | [IEvaluable and IEvaluator] | [IEvaluable] </pre> where the topmost evaluator is the optimizer and the bottommost evaluable is the optimization problem. The meaning of this picture is that the optimizer produces points and sends them through the chain to the problem. The problem evaluates the points, assigning each point its objective value(s). These are read by the optimizer which then tries to create better points, etc. The same kind of interaction chain is possible for learners and data sources. But there, the information flow is mainly in unidirectional: from the data source to the data sink. The class that represents solutions to optimization problems is <code>Solution</code>. Every instance of this class is a solution to the optimization problem. Each <code>Solution</code> object contains the design variables that define the solution and one or more objective values that assess the quality of the solution. The goal of each optimization algorithm is to find a <code>Solution</code> with minimal objective values. An object of the class <code>Data</code> represents the data involved in a particular learning setup. It is passed from data source to data sink. Often, <code>Modules</code> look similar, and someone writing a new <code>Module</code> doesn't want to implement all interface methods by hand. For these cases, we wrote the abstract classes <code>org.openopal.core.modules.optimization.Optimizer</code> and <code>Problem</code> and <code>learning.Learner</code>. These classes already implement almost all necessary methods. A writer of an optimizer just has to implement the algorithm itself and no other details (e.g. linking, checking etc.). Similarly, a writer of a problem just has to implement the evaluate method of the <code>Problem</code> class. In a learner, the method to override is run(). It executes the learning algorithm. ==The Interfaces== ===IModule=== This is the basic interface implemented by all modules. It contains methods for the initialisation and checking of the module and for the management of the options of the module. ===IRunnable=== This interfaces is implemented by all modules that can be run. When a module is run, it executes its optimization algorithm. In the future this could be any kind of algorithm. The interface contains methods to start and stop the execution of the module. ===IEvaluable=== Every module that represents an optimization problem implements the interface IEvaluable. This means that the module can evaluate a given solution. To that end, it looks at the design variables of a solution object it gets from an optimizer and sets the objective value(s) of that object accordingly. If a module is linked before a problem module, it must implement IEvaluable and delegate the evaluation of the solutions to the problem module. Thus, the optmimizer doesn't know if the module right after it is the problem itself or an intermediate module, it just calls the evaluate method of its successor module. IEvaluable contains methods to evaluate one solution or an array of solutions and a method to get the properties of the problem. ===IEvaluator=== A module that can call an evaluable to evaluate solutions implements the interface IEvaluator. Normally, an evaluator is an optimizer module, but any intermediate module between the optimizer and the problem must implement this interface as well. Otherwise, it wouldn't be able to call the problem to evaluate the solutions. IEvaluator contains methods to get and set the references to the evaluables and to check if these links are OK. ===IDataSource=== A module that provides data. This can be a file reader, the protocoller, or other modules that can produce or store data. The getData() method is the most important one. ===IDataSink=== A module implementing this interface represents a learner. It is linked with a data source and processes the given data. Very different kinds of processing are possible. A data viewer can just display the data, a neural network can learn a function from the data or a statistics module can compute some statistics on the data etc. 92 91 2013-03-18T20:58:00Z Dirk 2 /* Basics */ wikitext text/x-wiki ==Basics== The basic element of each OpenOpal optimization or learning environment is still the <code>Module</code>. Each optimization problem, each optimization algorithm and each learning algorithm is a module. A class that is used as a module must implement the interface <code>org.openopal.core.modules.IModule</code> (see [[Documentation/IModule | IModule]]). The whole structure of modules in OpenOpal is based on interfaces. The reason for this is that classes that are used as <code>Modules</code> may be part of a class hierarchy and thus they cannot inherit from a basic module class. There are <code>Modules</code> that can be run, e.g. optimization algorithms. All these modules implement the interface <code>org.openopal.core.modules.IRunnable</code>. Each optimization setup consists of at least two linked <code>Modules</code>: a problem and an optimizer. The interfaces for these modules are <code>org.openopal.core.modules.optimization.IEvaluable</code> and <code>IEvaluator</code>, respecively. The corresponding pair for a learning task is <code>org.openopal.core.modules.learning.IDataSource</code> and <code>IDataSink</code>. Modules can be linked between other modules. E.g. the protocoller is a <code>Module</code> that you can link between an optimizer and a problem. In such a case, all <code>Modules</code> except the optimizer must implement the interface <code>Evaluable</code> and all modules except the problem must implement the interface <code>IEvaluator</code>. This means that the modules form a chain that looks like this (here, two intermediate modules are shown): <pre> [IEvaluator] | [IEvaluable and IEvaluator] | [IEvaluable and IEvaluator] | [IEvaluable] </pre> where the topmost evaluator is the optimizer and the bottommost evaluable is the optimization problem. The meaning of this picture is that the optimizer produces points and sends them through the chain to the problem. The problem evaluates the points, assigning each point its objective value(s). These are read by the optimizer which then tries to create better points, etc. The same kind of interaction chain is possible for learners and data sources. But there, the information flow is mainly in unidirectional: from the data source to the data sink. ==The Interfaces== ===IModule=== This is the basic interface implemented by all modules. It contains methods for the initialisation and checking of the module and for the management of the options of the module. ===IRunnable=== This interfaces is implemented by all modules that can be run. When a module is run, it executes its optimization algorithm. In the future this could be any kind of algorithm. The interface contains methods to start and stop the execution of the module. ===IEvaluable=== Every module that represents an optimization problem implements the interface IEvaluable. This means that the module can evaluate a given solution. To that end, it looks at the design variables of a solution object it gets from an optimizer and sets the objective value(s) of that object accordingly. If a module is linked before a problem module, it must implement IEvaluable and delegate the evaluation of the solutions to the problem module. Thus, the optmimizer doesn't know if the module right after it is the problem itself or an intermediate module, it just calls the evaluate method of its successor module. IEvaluable contains methods to evaluate one solution or an array of solutions and a method to get the properties of the problem. ===IEvaluator=== A module that can call an evaluable to evaluate solutions implements the interface IEvaluator. Normally, an evaluator is an optimizer module, but any intermediate module between the optimizer and the problem must implement this interface as well. Otherwise, it wouldn't be able to call the problem to evaluate the solutions. IEvaluator contains methods to get and set the references to the evaluables and to check if these links are OK. ===IDataSource=== A module that provides data. This can be a file reader, the protocoller, or other modules that can produce or store data. The getData() method is the most important one. ===IDataSink=== A module implementing this interface represents a learner. It is linked with a data source and processes the given data. Very different kinds of processing are possible. A data viewer can just display the data, a neural network can learn a function from the data or a statistics module can compute some statistics on the data etc. 0 39 94 2013-03-18T21:07:47Z Dirk 2 Created page with "== Need for Classes == <code>Modules</code> are connected. The information passed between these <code>Modules</code> may be a class of type * <code>Solution</code>s in the cas..." wikitext text/x-wiki == Need for Classes == <code>Modules</code> are connected. The information passed between these <code>Modules</code> may be a class of type * <code>Solution</code>s in the case of an optimization or * <code>Data</code> in the case of learning Often, <code>Modules</code> look similar, and someone writing a new <code>Module</code> doesn't want to implement all interface methods by hand. For these cases, we wrote the abstract classes * <code>Optimizer</code>s in the case of an optimization algorithm * <code>Problem</code>s in the case of an optimization problem * <code>Learner</code>s in the case of a learning algorithm These classes already implement most of the necessary methods. A writer of an '''optimizer''' just has to implement the algorithm itself and no other details such as checking or connecting. Similarly, a writer of a '''problem''' just has to implement the <code>evaluate(...)</code> method of the <code>Problem</code> class. In a '''learner''', the method to override is <code>run()</code> . It executes the learning algorithm. 95 94 2013-03-18T21:08:21Z Dirk 2 /* Need for Classes */ wikitext text/x-wiki == Need for Classes == <code>Modules</code> are connected. The information passed between these <code>Modules</code> may be a class of type * <code>Solution</code>s in the case of an optimization or * <code>Data</code> in the case of learning Often, <code>Modules</code> look similar, and someone writing a new <code>Module</code> doesn't want to implement all interface methods by hand. For these cases, we wrote the abstract classes * <code>Optimizer</code>s in the case of an optimization algorithm * <code>Problem</code>s in the case of an optimization problem * <code>Learner</code>s in the case of a learning algorithm These classes already implement most of the necessary methods. A writer of an '''optimizer''' just has to implement the algorithm itself and no other details such as checking or connecting. Similarly, a writer of a '''problem''' just has to implement the <code>evaluate(...)</code> method of the <code>Problem</code> class. In a '''learner''', the method to override is <code>run()</code> . It executes the learning algorithm. 96 95 2013-03-18T21:08:37Z Dirk 2 wikitext text/x-wiki == Need for Classes == <code>Modules</code> are connected. The information passed between these <code>Modules</code> may be a class of type * <code>Solution</code>s in the case of an optimization or * <code>Data</code> in the case of learning Often, <code>Modules</code> look similar, and someone writing a new <code>Module</code> doesn't want to implement all interface methods by hand. For these cases, we wrote the abstract classes * <code>Optimizer</code>s in the case of an optimization algorithm * <code>Problem</code>s in the case of an optimization problem * <code>Learner</code>s in the case of a learning algorithm These classes already implement most of the necessary methods. A writer of an '''optimizer''' just has to implement the algorithm itself and no other details such as checking or connecting. Similarly, a writer of a '''problem''' just has to implement the <code>evaluate(...)</code> method of the <code>Problem</code> class. In a '''learner''', the method to override is <code>run()</code> . It executes the learning algorithm. 0 40 97 2013-03-18T21:13:01Z Dirk 2 Created page with "The compiled software can be downloaded from [[Download]] page. As the software is written in Java, the compiled code runs on most platforms. The software consists of a single ja..." wikitext text/x-wiki The compiled software can be downloaded from [[Download]] page. As the software is written in Java, the compiled code runs on most platforms. The software consists of a single jar file <tt>openopal.jar</tt>. After downloading, start OpenOpal with either: * double clicking on the jar (this is simple, however, not activated on all plattforms and console output may not be seen). * open a Linux shell or Windows Command Line and enter one of the following two command in the same directory as file <tt>openopal.jar</tt> was downloaded (Windows often requires the latter command). <pre>$ java -jar openopal.jar </pre> <pre>$ java -classpath openopal.jar org.openopal.core.OpenOpal</pre> * to see additional command line options enter <pre>$ java -jar openopal.jar -help </pre> 98 97 2013-03-18T21:27:41Z Dirk 2 wikitext text/x-wiki == Download == The compiled software can be downloaded from [[Download]] page. As the software is written in Java, the compiled code runs on most platforms. The software consists of a single jar file <tt>openopal.jar</tt>. == Start == Start OpenOpal with either: * double clicking on the jar (this is simple, however, not activated on all plattforms and console output may not be seen). * open a Linux shell or Windows Command Line and enter one of the following two command in the same directory as file <tt>openopal.jar</tt> was downloaded (Windows often requires the latter command). <pre>$ java -jar openopal.jar </pre> <pre>$ java -classpath openopal.jar org.openopal.core.OpenOpal</pre> * to see additional command line options enter <pre>$ java -jar openopal.jar -help </pre> == Writing a Shell Script == The script assumes an OpenOpal archive file <tt>openopal.jar</tt>. This filename can be replaced to match the actual name or by a filename with absolute path. In Windows, create a file <tt>openopal.bat</tt> with the following content: <pre>$java -cp openopal.jar org/openopal/core/OpenOpal %* /pre> In Linux, create a file <tt>openopal.sh</tt> with the following content: <pre> #!/bin/sh java -classpath openopal.jar org.openopal.core.OpenOpal $* /pre> To make the file executable enter in the shell: <pre> chmod u+x openopal.sh /pre> 99 98 2013-03-18T21:38:48Z Dirk 2 /* Writing a Shell Script */ wikitext text/x-wiki == Download == The compiled software can be downloaded from [[Download]] page. As the software is written in Java, the compiled code runs on most platforms. The software consists of a single jar file <tt>openopal.jar</tt>. == Start == Start OpenOpal with either: * double clicking on the jar (this is simple, however, not activated on all plattforms and console output may not be seen). * open a Linux shell or Windows Command Line and enter one of the following two command in the same directory as file <tt>openopal.jar</tt> was downloaded (Windows often requires the latter command). <pre>$ java -jar openopal.jar </pre> <pre>$ java -classpath openopal.jar org.openopal.core.OpenOpal</pre> * to see additional command line options enter <pre>$ java -jar openopal.jar -help </pre> == Writing a Shell Script == The script assumes an OpenOpal archive file <tt>openopal.jar</tt>. This filename can be replaced to match the actual name or by a filename with absolute path. In Windows, create a file <tt>openopal.bat</tt> with the following content: java -cp openopal.jar org/openopal/core/OpenOpal %* In Linux, create a file <tt>openopal.sh</tt> with the following content: #!/bin/sh java -classpath openopal.jar org.openopal.core.OpenOpal $* To make the file executable enter in the shell: chmod u+x openopal.sh 0 11 100 11 2013-03-18T21:46:36Z Dirk 2 /* Optimization Problems */ wikitext text/x-wiki '''Modules''' contain all the functionality for optimizing and learning. One '''Modules''' may contain an optimization algorithm, an artificial neural network, or a problem to optimize. Here is a list of documented modules in OpenOpal. Further modules may exist, but may not yet be documented. == Single Objective Optimization Algorithms == === Indirect, Deterministic Algorithms === Not implemented, yet. === Direct, Deterministic Algorithms === * [[Documentation/Modules/OptAlgSIMPLEX | <code>OptAlgSIMPLEX</code>: Nelder-Mead Simplex Algorithm]] === Indirect, Stochastic Algorithms === * Evolutionary Algorithms ** [[Documentation/Modules/OptAlgOpO|<code>OptAlgOpO</code>: 1+1 Evolution Strategy with 1/5 Success Rule]] ** [[Documentation/Modules/OptAlgCMA|<code>OptAlgCMA</code>: A Multi-member Evolution Strategy with Covariance Matrix Adaptation]] == Single and Multi-Objective Optimization Algorithms == === Indirect, Stochastic Algorithms === * Evolutionary Algorithms ** [[Documentation/Modules/OptAlgMoCMA | <code>OptAlgMoCMA</code>: Elitist Evolution Strategy with Covariance Matrix Adaptation]] * Particle Methods ** [[Documentation/Modules/OptAlgMOPSO | <code>OptAlgMOPSO</code>: Particle Swarm Optimization Algorithm]] == Design of Experiments == * [[Documentation/Modules/DoePlanner | <code>DoePlanner</code>: A Module Containing Different DoE plans]] * [[Documentation/Modules/RandomSampling | <code>RandomSampling</code>: Uniform Random Sampling]] == Optimization in General == * [[Documentation/Modules/BoundHandler | <code>BoundHandler</code> For Optimization Algorithms Without Bound Handling]] * [[Documentation/Modules/ContinuousTestProblems | <code>ContinuousTestProblems </code>: A Set of Single Objective Test Problem]] * [[Documentation/Modules/ContinuousMOTestProblems | <code>ContinuousMOTestProblems </code>: A Set of Multi-Objective Test Problem]] == Optimization Problems == * [[Documentation/Modules/ProblemSimple | <code>ProblemSimple</code> A Simple Test Problem]] * [[Documentation/Modules/ContinuousTestProblems | <code>ContinuousTestProblems </code>: A Set of Single Objective Test Problem]] * [[Documentation/Modules/ContinuousMOTestProblems | <code>ContinuousMOTestProblems </code>: A Set of Multi-Objective Test Problem]] == Machine Learning == * [[Documentation/Modules/NeuralNetwork | <code>NeuralNetwork</code>: Artificial Neural Network]] == Miscellaneous Modules == * [[Documentation/Modules/SurrogateManager | <code>SurrogateManager</code>: A Framework for Surrogate Managing]] 101 100 2013-03-18T21:46:46Z Dirk 2 /* Optimization in General */ wikitext text/x-wiki '''Modules''' contain all the functionality for optimizing and learning. One '''Modules''' may contain an optimization algorithm, an artificial neural network, or a problem to optimize. Here is a list of documented modules in OpenOpal. Further modules may exist, but may not yet be documented. == Single Objective Optimization Algorithms == === Indirect, Deterministic Algorithms === Not implemented, yet. === Direct, Deterministic Algorithms === * [[Documentation/Modules/OptAlgSIMPLEX | <code>OptAlgSIMPLEX</code>: Nelder-Mead Simplex Algorithm]] === Indirect, Stochastic Algorithms === * Evolutionary Algorithms ** [[Documentation/Modules/OptAlgOpO|<code>OptAlgOpO</code>: 1+1 Evolution Strategy with 1/5 Success Rule]] ** [[Documentation/Modules/OptAlgCMA|<code>OptAlgCMA</code>: A Multi-member Evolution Strategy with Covariance Matrix Adaptation]] == Single and Multi-Objective Optimization Algorithms == === Indirect, Stochastic Algorithms === * Evolutionary Algorithms ** [[Documentation/Modules/OptAlgMoCMA | <code>OptAlgMoCMA</code>: Elitist Evolution Strategy with Covariance Matrix Adaptation]] * Particle Methods ** [[Documentation/Modules/OptAlgMOPSO | <code>OptAlgMOPSO</code>: Particle Swarm Optimization Algorithm]] == Design of Experiments == * [[Documentation/Modules/DoePlanner | <code>DoePlanner</code>: A Module Containing Different DoE plans]] * [[Documentation/Modules/RandomSampling | <code>RandomSampling</code>: Uniform Random Sampling]] == Optimization in General == * [[Documentation/Modules/BoundHandler | <code>BoundHandler</code> For Optimization Algorithms Without Bound Handling]] == Optimization Problems == * [[Documentation/Modules/ProblemSimple | <code>ProblemSimple</code> A Simple Test Problem]] * [[Documentation/Modules/ContinuousTestProblems | <code>ContinuousTestProblems </code>: A Set of Single Objective Test Problem]] * [[Documentation/Modules/ContinuousMOTestProblems | <code>ContinuousMOTestProblems </code>: A Set of Multi-Objective Test Problem]] == Machine Learning == * [[Documentation/Modules/NeuralNetwork | <code>NeuralNetwork</code>: Artificial Neural Network]] == Miscellaneous Modules == * [[Documentation/Modules/SurrogateManager | <code>SurrogateManager</code>: A Framework for Surrogate Managing]] 0 41 102 2013-03-18T21:48:07Z Dirk 2 Created page with "==Summary== Some optimizations require bounds on the design variables '''xxx'''. E.g. for the diameter of any mechanical support must be above a certain minimum value. As not a..." wikitext text/x-wiki ==Summary== Some optimizations require bounds on the design variables '''xxx'''. E.g. for the diameter of any mechanical support must be above a certain minimum value. As not all optimization algorithms include bound handling, the module <code>BoundHandler</code> was created. ==Properties== ===General=== {| class="wikitable" style="text-align:left" border="2" cellpadding="5" cellspacing="5" |- ! Algorithm | deterministic. |- ! Design Variables | Continuous variables, discrete or mixed variables are possible. |- ! Objectives | any number. |- ! Constraints | any number. |- ! Boundaries | Design variables values outside the boundaries are corrected. |- ! Initial Search Region | not affected. |- ! Typical X | not affected. |- ! Initialization | not required. |- |} ===Connections=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Starting at his module | One connection of type <code>optimization</code> |- ! Ending at this module | One connection of type <code>optimization</code> |- |} ===Actions=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Name !! Description |- ! - | - |- |} ===Options=== The options are currently described as "pop-up help". ==Module Description== Any optimization algorithm proposes a new solution '''x'''. Some of the values of '''x''' might be outside the lower bounds x_l and upper bounds x_u, specified in the "Problem" module. These variables are corrected to values within the bounds by two different methods: 1. set to bounds If one of the variables x is below or above the bounds, it is set to the bound value, i.e. if x < x_l, then x = x_l else if x > x_u, then x = x_u 2. reflect If one of the variables x is below or above the bounds, it is reflected from the bound. The reflection is done such that if x goes to infinity, x is equal to the lower bound and if x goes to minus infinity, it is set to the upper bound. if x < x_l, then x = x_u + (x_l- x_u) / (x - x_u) * (x_l- x_u); else if x > x_u, then x = x_l + (x_u- x_l) / (x - x_l) * (x_u- x_l) ==Usage== - ==Source Code== ToDo:Link to SVN ==References== - 2 42 104 2013-06-05T19:08:58Z Dirk 2 Created page with "this page is private" wikitext text/x-wiki this page is private 105 104 2013-06-05T19:10:44Z Dirk 2 wikitext text/x-wiki Dirk Bueche 8 30 106 59 2013-06-05T19:32:58Z Admin 1 wikitext text/x-wiki * SEARCH * navigation ** mainpage|mainpage-description ** documentation|Documentation ** download| Download ** screenshots|Screen Shots ** recentchanges-url|recentchanges ** randompage-url|randompage * TOOLBOX * LANGUAGES 107 106 2013-06-05T19:40:05Z Admin 1 wikitext text/x-wiki * SEARCH * navigation ** mainpage|mainpage-description ** Documentations|documentation ** Download|download ** screenshots|Screen Shots ** recentchanges-url|recentchanges ** randompage-url|randompage * TOOLBOX * LANGUAGES 108 107 2013-06-05T19:41:01Z Admin 1 wikitext text/x-wiki * SEARCH * navigation ** mainpage|mainpage-description ** documentation|Documentation-description ** download|Download ** screenshots|Screen Shots ** recentchanges-url|recentchanges ** randompage-url|randompage * TOOLBOX * LANGUAGES 109 108 2013-06-05T19:41:39Z Admin 1 wikitext text/x-wiki * SEARCH * navigation ** mainpage|mainpage-description ** documentation|Documentation ** download|DownloadX ** screenshots|Screen Shots ** recentchanges-url|recentchanges ** randompage-url|randompage * TOOLBOX * LANGUAGES 8 30 110 109 2013-06-05T19:41:56Z Admin 1 wikitext text/x-wiki * SEARCH * navigation ** mainpage|mainpage-description ** documentation|Documentation ** download|Downloads ** screenshots|Screen Shots ** recentchanges-url|recentchanges ** randompage-url|randompage * TOOLBOX * LANGUAGES 111 110 2013-06-05T20:18:50Z Admin 1 wikitext text/x-wiki * SEARCH * Navigation ** mainpage|mainpage-description ** documentation|Documentation ** download|Downloads ** screenshots|Screen Shots * TOOLBOX ** recentchanges-url|recentchanges ** randompage-url|randompage * LANGUAGES 112 111 2013-06-05T20:19:29Z Admin 1 wikitext text/x-wiki * SEARCH * Navigation ** mainpage|mainpage-description ** documentation|Documentation ** download|Downloads ** screenshots|Screen Shots * TOOLBOX * Other Pages ** recentchanges-url|recentchanges ** randompage-url|randompage * LANGUAGES 0 2 113 60 2013-09-12T20:04:54Z Admin 1 wikitext text/x-wiki = Welcome to '''OpenDINO''' = '''OpenDINO ''' is an open source platform for optimization, design of experiment and learning. The code bases on [OpenOpal], a project created in a cooperation of two universities which has been terminated. OpenOpal is written in Java. Contact: * [mailto:help@opendino.org help@opendino.org] 114 113 2013-09-12T20:10:05Z Admin 1 wikitext text/x-wiki = Welcome to '''OpenDINO''' = '''OpenDINO ''' is an open source platform for optimization, design of experiment and learning. The code bases on [http://www.openopal.org OpenOpal], a project created in a cooperation of two universities which has been terminated. OpenOpal is written in Java. Contact: * [mailto:help@opendino.org help@opendino.org] 129 114 2013-09-27T18:38:14Z Dirk 2 /* Welcome to OpenDINO */ wikitext text/x-wiki = Welcome to '''OpenDINO''' = '''OpenDINO ''' is an open source platform for optimization, design of experiment and learning. The platform is a successor of the terminated [http://www.openopal.org OpenOpal] project. '''OpenDINO''' is written in Java. Contact: * [mailto:help@opendino.org help@opendino.org] 138 129 2014-03-18T22:11:35Z Dirk 2 /* Welcome to OpenDINO */ wikitext text/x-wiki = Welcome to '''OpenDino''' = '''OpenDino ''' is an open source platform for optimization, design of experiment and learning. The platform is a successor of the terminated [http://www.openopal.org OpenOpal] project. '''OpenDino''' is written in Java. Contact: * [mailto:help@opendino.org help@opendino.org] 0 3 115 3 2013-09-12T20:11:33Z Admin 1 wikitext text/x-wiki == The Main Window == After starting software, the main '''GUI''' appears (Fig. 1). The figure contains an example for an optimization using 4 '''Module'''s. Each module has a name and an unique ID. OpenOpal is a strictly modular software. All functionality for automated optimization and machine learning is encoded in the modules. Here: Module 1 (<code>OptAlgCMA</code>) is an optimization algorithm. It is connected via Module 3 (<code>Protocoller</code>) with Module 2 (<code>ProblemSimple</code>). Module 2 contains the optimization problem, i.e. the function to minimize. Here, it is a simple continuous, quadratic function. Module 3 (<code>Protocoller</code>) is a protocoling module, i.e. it stores all evaluated solutions of an optimization run. These solutions can be visualized with Module 4 (<code>DataViewer</code>). [[Image:OpenOpalMainGUI.png|frame|center|Figure 1: Main GUI of OpenOpal]] == Adding, Editing, and Connecting Modules == Right-clicking on the dotted area or on a module opens a dialogue as shown in Fig. 2. This dialogue supports: * adding modules (if clicked on a free space) * removing modules or changing the options of a module when clicking on a module * adding/removing connections between modules * checking and running modules In Fig. 2, the right-click is made on Module 4, e.g. for setting the options of this module. [[Image:OpenOpalModuleRightclick.png|frame|center|Figure 2: Editing Modules]] == Running an Optimization == Right-clicking Module 1 and selecting the option <code>Run</code> starts an optimization. The standard output of the optimization is given in the lower part of the main window in Fig. 3. [[Image:OpenOpalOptimization.png|frame|center|Figure 3: Running an Optimization]] == Postprocessing an Optimization == Right-clicking Module 4 and selecting the option <code>Run</code> starts an the data viewer. Figure 4 shows the evolution of the objective function ''f'' over the number of evaluations. As the objective function is a simple quadratic function (x^2), the minimal function value is zero, which is approximated by 1e-12. [[Image:OpenOpalDataViewer.png|frame|center|Figure 4: Postprocessing an Optimization with the DataViewer module. ]] == References == Input file behind screen shots is stored in the SVN repository ToDo: Link. 116 115 2013-09-12T20:12:42Z Admin 1 wikitext text/x-wiki == The Main Window == After starting software, the main '''GUI''' appears (Fig. 1). The figure contains an example for an optimization using 4 '''Module'''s. Each module has a name and an unique ID. The software is a strictly modular. All functionality for automated optimization and machine learning is encoded in the modules. Here: Module 1 (<code>OptAlgCMA</code>) is an optimization algorithm. It is connected via Module 3 (<code>Protocoller</code>) with Module 2 (<code>ProblemSimple</code>). Module 2 contains the optimization problem, i.e. the function to minimize. Here, it is a simple continuous, quadratic function. Module 3 (<code>Protocoller</code>) is a protocoling module, i.e. it stores all evaluated solutions of an optimization run. These solutions can be visualized with Module 4 (<code>DataViewer</code>). [[Image:OpenOpalMainGUI.png|frame|center|Figure 1: Main GUI of OpenDINO]] == Adding, Editing, and Connecting Modules == Right-clicking on the dotted area or on a module opens a dialogue as shown in Fig. 2. This dialogue supports: * adding modules (if clicked on a free space) * removing modules or changing the options of a module when clicking on a module * adding/removing connections between modules * checking and running modules In Fig. 2, the right-click is made on Module 4, e.g. for setting the options of this module. [[Image:OpenOpalModuleRightclick.png|frame|center|Figure 2: Editing Modules]] == Running an Optimization == Right-clicking Module 1 and selecting the option <code>Run</code> starts an optimization. The standard output of the optimization is given in the lower part of the main window in Fig. 3. [[Image:OpenOpalOptimization.png|frame|center|Figure 3: Running an Optimization]] == Postprocessing an Optimization == Right-clicking Module 4 and selecting the option <code>Run</code> starts an the data viewer. Figure 4 shows the evolution of the objective function ''f'' over the number of evaluations. As the objective function is a simple quadratic function (x^2), the minimal function value is zero, which is approximated by 1e-12. [[Image:OpenOpalDataViewer.png|frame|center|Figure 4: Postprocessing an Optimization with the DataViewer module. ]] == References == Input file behind screen shots is stored in the SVN repository ToDo: Link. 131 116 2014-03-18T20:04:23Z Dirk 2 wikitext text/x-wiki == The Main Window == After starting software, the main '''GUI''' appears (Fig. 1). The figure contains an example for an optimization using 4 '''Module'''s. Each module has a name and an unique ID. The software is a strictly modular. All functionality for automated optimization and machine learning is encoded in the modules. Here: Module 1 (<code>OptAlgCMA</code>) is an optimization algorithm. It is connected via Module 3 (<code>Protocoller</code>) with Module 2 (<code>ProblemSimple</code>). Module 2 contains the optimization problem, i.e. the function to minimize. Here, it is a simple continuous, quadratic function. Module 3 (<code>Protocoller</code>) is a protocoling module, i.e. it stores all evaluated solutions of an optimization run. These solutions can be visualized with Module 4 (<code>DataViewer</code>). [[Image:MainGUI.png|frame|center|Figure 1: Main GUI of OpenDINO]] == Adding, Editing, and Connecting Modules == Right-clicking on the dotted area or on a module opens a dialogue as shown in Fig. 2. This dialogue supports: * adding modules (if clicked on a free space) * removing modules or changing the options of a module when clicking on a module * adding/removing connections between modules * checking and running modules In Fig. 2, the right-click is made on Module 4, e.g. for setting the options of this module. [[Image:ModuleRightclick.png|frame|center|Figure 2: Editing Modules]] == Running an Optimization == Right-clicking Module 1 and selecting the option <code>Run</code> starts an optimization. The standard output of the optimization is given in the lower part of the main window in Fig. 3. [[Image:Optimization.png|frame|center|Figure 3: Running an Optimization]] == Postprocessing an Optimization == Right-clicking Module 4 and selecting the option <code>Run</code> starts an the data viewer. Figure 4 shows the evolution of the objective function ''f'' over the number of evaluations. As the objective function is a simple quadratic function (x^2), the minimal function value is zero, which is approximated by 1e-12. [[Image:DataViewer.png|frame|center|Figure 4: Postprocessing an Optimization with the DataViewer module. ]] == References == Input file behind screen shots is stored in the SVN repository ToDo: Link. 149 131 2014-03-19T22:04:15Z Admin 1 wikitext text/x-wiki == The Main Window == After starting software, the main '''GUI''' appears (Fig. 1). The figure contains an example for an optimization using 4 '''Module'''s. Each module has a name and an unique ID. The software is a strictly modular. All functionality for automated optimization and machine learning is encoded in the modules. Here: Module 1 (<code>OptAlgCMA</code>) is an optimization algorithm. It is connected via Module 3 (<code>Protocoller</code>) with Module 2 (<code>ProblemSimple</code>). Module 2 contains the optimization problem, i.e. the function to minimize. Here, it is a simple continuous, quadratic function. Module 3 (<code>Protocoller</code>) is a protocoling module, i.e. it stores all evaluated solutions of an optimization run. These solutions can be visualized with Module 4 (<code>DataViewer</code>). [[Image:MainGUI.png|frame|center|Figure 1: Main GUI of OpenDino]] == Adding, Editing, and Connecting Modules == Right-clicking on the dotted area or on a module opens a dialogue as shown in Fig. 2. This dialogue supports: * adding modules (if clicked on a free space) * removing modules or changing the options of a module when clicking on a module * adding/removing connections between modules * checking and running modules In Fig. 2, the right-click is made on Module 4, e.g. for setting the options of this module. [[Image:ModuleRightclick.png|frame|center|Figure 2: Editing Modules]] == Running an Optimization == Right-clicking Module 1 and selecting the option <code>Run</code> starts an optimization. The standard output of the optimization is given in the lower part of the main window in Fig. 3. [[Image:Optimization.png|frame|center|Figure 3: Running an Optimization]] == Postprocessing an Optimization == Right-clicking Module 4 and selecting the option <code>Run</code> starts an the data viewer. Figure 4 shows the evolution of the objective function ''f'' over the number of evaluations. As the objective function is a simple quadratic function (x^2), the minimal function value is zero, which is approximated by 1e-12. [[Image:DataViewer.png|frame|center|Figure 4: Postprocessing an Optimization with the DataViewer module. ]] == References == Input file behind screen shots is stored in the SVN repository ToDo: Link. 0 11 117 101 2013-09-12T20:13:39Z Admin 1 wikitext text/x-wiki '''Modules''' contain all the functionality for optimizing and learning. One '''Modules''' may contain an optimization algorithm, an artificial neural network, or a problem to optimize. Here is a list of documented modules in OpenDINO. Further modules may exist, but may not yet be documented. == Single Objective Optimization Algorithms == === Indirect, Deterministic Algorithms === Not implemented, yet. === Direct, Deterministic Algorithms === * [[Documentation/Modules/OptAlgSIMPLEX | <code>OptAlgSIMPLEX</code>: Nelder-Mead Simplex Algorithm]] === Indirect, Stochastic Algorithms === * Evolutionary Algorithms ** [[Documentation/Modules/OptAlgOpO|<code>OptAlgOpO</code>: 1+1 Evolution Strategy with 1/5 Success Rule]] ** [[Documentation/Modules/OptAlgCMA|<code>OptAlgCMA</code>: A Multi-member Evolution Strategy with Covariance Matrix Adaptation]] == Single and Multi-Objective Optimization Algorithms == === Indirect, Stochastic Algorithms === * Evolutionary Algorithms ** [[Documentation/Modules/OptAlgMoCMA | <code>OptAlgMoCMA</code>: Elitist Evolution Strategy with Covariance Matrix Adaptation]] * Particle Methods ** [[Documentation/Modules/OptAlgMOPSO | <code>OptAlgMOPSO</code>: Particle Swarm Optimization Algorithm]] == Design of Experiments == * [[Documentation/Modules/DoePlanner | <code>DoePlanner</code>: A Module Containing Different DoE plans]] * [[Documentation/Modules/RandomSampling | <code>RandomSampling</code>: Uniform Random Sampling]] == Optimization in General == * [[Documentation/Modules/BoundHandler | <code>BoundHandler</code> For Optimization Algorithms Without Bound Handling]] == Optimization Problems == * [[Documentation/Modules/ProblemSimple | <code>ProblemSimple</code> A Simple Test Problem]] * [[Documentation/Modules/ContinuousTestProblems | <code>ContinuousTestProblems </code>: A Set of Single Objective Test Problem]] * [[Documentation/Modules/ContinuousMOTestProblems | <code>ContinuousMOTestProblems </code>: A Set of Multi-Objective Test Problem]] == Machine Learning == * [[Documentation/Modules/NeuralNetwork | <code>NeuralNetwork</code>: Artificial Neural Network]] == Miscellaneous Modules == * [[Documentation/Modules/SurrogateManager | <code>SurrogateManager</code>: A Framework for Surrogate Managing]] 151 117 2014-03-19T22:05:23Z Admin 1 wikitext text/x-wiki '''Modules''' contain all the functionality for optimizing and learning. One '''Modules''' may contain an optimization algorithm, an artificial neural network, or a problem to optimize. Here is a list of documented modules in OpenDino. Further modules may exist, but may not yet be documented. == Single Objective Optimization Algorithms == === Indirect, Deterministic Algorithms === Not implemented, yet. === Direct, Deterministic Algorithms === * [[Documentation/Modules/OptAlgSIMPLEX | <code>OptAlgSIMPLEX</code>: Nelder-Mead Simplex Algorithm]] === Indirect, Stochastic Algorithms === * Evolutionary Algorithms ** [[Documentation/Modules/OptAlgOpO|<code>OptAlgOpO</code>: 1+1 Evolution Strategy with 1/5 Success Rule]] ** [[Documentation/Modules/OptAlgCMA|<code>OptAlgCMA</code>: A Multi-member Evolution Strategy with Covariance Matrix Adaptation]] == Single and Multi-Objective Optimization Algorithms == === Indirect, Stochastic Algorithms === * Evolutionary Algorithms ** [[Documentation/Modules/OptAlgMoCMA | <code>OptAlgMoCMA</code>: Elitist Evolution Strategy with Covariance Matrix Adaptation]] * Particle Methods ** [[Documentation/Modules/OptAlgMOPSO | <code>OptAlgMOPSO</code>: Particle Swarm Optimization Algorithm]] == Design of Experiments == * [[Documentation/Modules/DoePlanner | <code>DoePlanner</code>: A Module Containing Different DoE plans]] * [[Documentation/Modules/RandomSampling | <code>RandomSampling</code>: Uniform Random Sampling]] == Optimization in General == * [[Documentation/Modules/BoundHandler | <code>BoundHandler</code> For Optimization Algorithms Without Bound Handling]] == Optimization Problems == * [[Documentation/Modules/ProblemSimple | <code>ProblemSimple</code> A Simple Test Problem]] * [[Documentation/Modules/ContinuousTestProblems | <code>ContinuousTestProblems </code>: A Set of Single Objective Test Problem]] * [[Documentation/Modules/ContinuousMOTestProblems | <code>ContinuousMOTestProblems </code>: A Set of Multi-Objective Test Problem]] == Machine Learning == * [[Documentation/Modules/NeuralNetwork | <code>NeuralNetwork</code>: Artificial Neural Network]] == Miscellaneous Modules == * [[Documentation/Modules/SurrogateManager | <code>SurrogateManager</code>: A Framework for Surrogate Managing]] 0 10 118 93 2013-09-12T20:14:26Z Admin 1 wikitext text/x-wiki == Download == * [[Download | Executable]] * [[Documentation/Download/SVN | Source Code]] * [[Documentation/Software/Requirements | Software Requirements]] == Theory == * [[Documentation/DoE | Introduction to Design of Experiment]] * [[Documentation/Optimization | Introduction to Automated Optimization]] * [[Documentation/Machine_Learning | Introduction to Machine Learning]] * [[Documentation/Notation | Symbols and Notation]] == Users' Guide == * [[screenshots | A First Introduction to OpenDINO in the Screenshots]] * [[Installation | Installation]] * [[Documentation/Modules | Module Documentation]] == Developers' Guide == * [[Documentation/Compiling | Developing and Compiling]] * Concepts behind OpenDINO ** [[Documentation/Modules/TheCode | The 3 Main Parts]] ** [[Documentation/Modules/Execution | Module Execution]] ** [[Documentation/Modules/IModule | Interface <code>IModule</code> - The Obligatory Interface for Modules]] ** [[Documentation/Modules/Interfaces | Interfaces of Modules]] ** [[Documentation/Modules/ClassesModules | Abstract Modules and Classes]] == Various == * [[Documentation/Related | Links and Related Software]] 139 118 2014-03-19T20:03:51Z Dirk 2 wikitext text/x-wiki == Requirements == * [[Documentation/Software/Requirements | Software Requirements]] == Users' Guide == * [[Installation | Installation]] * [[Screenshots | A First Introduction to OpenDINO in the Screenshots]] * [[Documentation/Modules | Module Documentation]] == Theory == * [[Documentation/DoE | Introduction to Design of Experiment]] * [[Documentation/Optimization | Introduction to Automated Optimization]] * [[Documentation/Machine_Learning | Introduction to Machine Learning]] * [[Documentation/Notation | Symbols and Notation]] == Developers' Guide == * [[Download | Download]] * [[Documentation/Compiling | Developing and Compiling]] * Concepts behind OpenDINO ** [[Documentation/Modules/TheCode | The 3 Main Parts]] ** [[Documentation/Modules/Execution | Module Execution]] ** [[Documentation/Modules/IModule | Interface <code>IModule</code> - The Obligatory Interface for Modules]] ** [[Documentation/Modules/Interfaces | Interfaces of Modules]] ** [[Documentation/Modules/ClassesModules | Abstract Modules and Classes]] == Various == * [[Documentation/Related | Links and Related Software]] 150 139 2014-03-19T22:04:54Z Admin 1 wikitext text/x-wiki == Requirements == * [[Documentation/Software/Requirements | Software Requirements]] == Users' Guide == * [[Installation | Installation]] * [[Screenshots | A First Introduction to OpenDino in the Screenshots]] * [[Documentation/Modules | Module Documentation]] == Theory == * [[Documentation/DoE | Introduction to Design of Experiment]] * [[Documentation/Optimization | Introduction to Automated Optimization]] * [[Documentation/Machine_Learning | Introduction to Machine Learning]] * [[Documentation/Notation | Symbols and Notation]] == Developers' Guide == * [[Download | Download]] * [[Documentation/Compiling | Developing and Compiling]] * Concepts behind OpenDino ** [[Documentation/Modules/TheCode | The 3 Main Parts]] ** [[Documentation/Modules/Execution | Module Execution]] ** [[Documentation/Modules/IModule | Interface <code>IModule</code> - The Obligatory Interface for Modules]] ** [[Documentation/Modules/Interfaces | Interfaces of Modules]] ** [[Documentation/Modules/ClassesModules | Abstract Modules and Classes]] == Various == * [[Documentation/Related | Links and Related Software]] 159 150 2015-10-21T18:51:26Z Dirk 2 wikitext text/x-wiki == Requirements == * [[Documentation/Software/Requirements | Software Requirements]] == Users' Guide == * [[Installation | Installation]] * [[Screenshots | A First Introduction to OpenDino in the Screenshots]] * [[Documentation/Notation | Symbols and Notation]] * [[Documentation/Modules | Module Documentation]] == Theory == * [[Documentation/DoE | Introduction to Design of Experiment]] * [[Documentation/Optimization | Introduction to Automated Optimization]] * [[Documentation/Machine_Learning | Introduction to Machine Learning]] == Developers' Guide == * [[Download | Download]] * [[Documentation/Compiling | Developing and Compiling]] * Concepts behind OpenDino ** [[Documentation/Modules/TheCode | The 3 Main Parts]] ** [[Documentation/Modules/Execution | Module Execution]] ** [[Documentation/Modules/IModule | Interface <code>IModule</code> - The Obligatory Interface for Modules]] ** [[Documentation/Modules/Interfaces | Interfaces of Modules]] ** [[Documentation/Modules/ClassesModules | Abstract Modules and Classes]] == Various == * [[Documentation/Related | Links and Related Software]] 0 20 119 24 2013-09-12T20:15:11Z Admin 1 wikitext text/x-wiki =Design of Experiments= == Introduction == Design of Experiments ('''DoE''') defines methods of how to plan and arrange experiments. We explain the method using the example of a baker in a bakery. The baker wants to analyze the effect of different settings of his oven to the quality of the resulting bread by conducting several experiments. === Target Values === We define the targets of experiments (here to improve the quality of the bread) as '''target values'''. === Input Parameters === All sources of influence on the target values are referred to as '''factors'''. Three different groups of factors are distinguished: # ''noise factors'': These factors cannot be controlled or controlling these factors is too expensive. As an example, the temperature and humidity in the bakery depends on the season and weather and cannot be controlled. # ''control factors'': These factors can be controlled. However, their influence on the target value is not of interest and thus, these factors are set constant. For example, the baker wants to leave his recipe for the bread unchanged. # ''signal factors'': These factors can be controlled. Their influence is of interest and their values are modified in the experiments. DoE is important when we have to analyze a process with multiple signal factors, in order to determine their effect on the target value(s). '''''Note:''' In the following, we will only consider signal factors. For simplicity, they are referred to as factors.'' === Factor Levels === For each factor, we may want to analyze different values. For example, we want to analyze an oven temperature of 185, 190, 195, and 200^oC and a baking time of 45, 50, 55 and 60 minutes. These different values are referred to as ''factor levels''. === Experiment === One experiment is one combination of different factor levels and the corresponding target values for the experiment. For example, one experiment may be a temperature of 190^oC and a baking time of 60 min. One experiment is also referred to as one '''factor level combination'''. === DoE Plan === The DoE plan defines which experiments are to be conducted and in which sequence they are conducted. The sequence may be important as environmental conditions like temperature may effect the target values as well as hysteresis effects. DoE plans differ in number of total experiments and the order of the experiments. The number of experiments strongly influences the information gain and the trust in the experiments. As references for DoE plans we recommend [ [[#klepp | 1]], [[#wikidoe | 2]] ]. == DoE Plans == A DoE plan can be considered as a set of rules describing how to choose factors, the number of factor levels, factor level values or value distributions, etc.. In the following, two different DoE plans are outlined. === Full Factorial === [[Image:DoEFullFactorial.png|frame|right|A two factor Full Factorial plan. Each square represents one possible experiment. The "X" denote the actual experiments that will be scheduled.]] For given numbers of factor levels for each variable, a limited number of different experiments can be conducted. A DoE plan with all possible experiments is referred to as '''Full Factorial''' plan: The number of factor levels may vary for the factors. All other plans use only a subset of all possible experiments. === Latin Hypercube === [[Image:DoELatinHypercube.png|frame|right|A two factor Latin Hypercube plan. Each square represents one possible experiment. The "X" denote the actual experiments that will be scheduled.]] Compared to the Full Factorial plan, the Latin Hypercube (LHC) sampling dramatically reduces the number of experiments (see e.g. [ [[#wikilhc | 3]] ]). So it is most useful for expensive experiments, whether they be money or time intensive. Latin Hypercube requires the same number of factor levels for all factors. The number of experiments of a LHC plan is equal to the number of factor levels and is independent on the number of factors. This makes it very scalable (O(1)) in respect of number of factors. The philosophy of LHC is to use every factor level exactly once. The figure on the right demonstrates a possible plan for 4 factor levels. As each factor level is only used once, each row and column in the figure must contain exactly one cross. Thus, LHC guaranties that for each factor, the entire range of factor levels is used. == Common Settings for all DoE Plans == The following list explains common settings for all DoE plans. === Number of Iterations === The testing of a set of experiments that a DoE plan proposes is referred to as one ''iteration''. If we would schedule three ''iterations'', each experiment (i.e. a certain factor level combination) in the set is tested exactly three times. Using more than one iteration is only necessary if the system to analyze is noisy (i.e. the target values are noisy), may contain a drift while testing, or produces hysteresis. === Random Scheduling === [[Image:DoERandomBlock.png|thumb|250px|right|Four different scheduling plans of six experiments resulting from DoE plan with three experiments and two iterations. The small double-bordered boxes outline the blocks.]] Without ''random scheduling'', the experiments are tested in a fixed order. With ''randomization'' activated, a random sequence for the experiment is set up. To what extend the randomization occurs depends on whether ''block building'' is active or not. ''Random scheduling'' may help to analyze effects like hysteresis, i.e. the previous experiment effects the outcome of the current experiment. If we run multiple iterations, the effect of hysteresis decreases because of statistical reasons. === Block Building === If ''block building'' is activated, all experiments of one iteration are tested. Then, all experiments of the next iteration are tested. If ''block building'' is '''de'''activated, experiments of different iterations may follow each other. ''Block building'', like ''random scheduling'', may reduce the effect that may occur because of the order in which the experiments get scheduled. While ''random scheduling'' may reduce the effect of subsequent experiments, activating ''block building'' may reduce the effect caused by external (long term) influences. These influences can be quality of the used materials, which may vary over time or depend on the supplier, human interaction with the machines or the accuracy of machines of the same type used for the experiments. == DoE in OpenDINO == A description for DoE in OpenDINO can be found in the module documentation (see [[Documentation/Modules/DoePlanner]]). == References == <span id="klepp">1</span> Wilhelm Kleppmann, Taschenbuch Versuchsplanung (4. Auflage) - Produkte und Prozesse optimieren, Carl Hanser Verlag Muenchen Wien, 2006 <span id="wikidoe">2</span> http://en.wikipedia.org/wiki/Design_of_experiments <span id="wikilhc">3</span> http://en.wikipedia.org/wiki/Latin_hypercube 158 119 2014-03-19T22:09:52Z Admin 1 wikitext text/x-wiki =Design of Experiments= == Introduction == Design of Experiments ('''DoE''') defines methods of how to plan and arrange experiments. We explain the method using the example of a baker in a bakery. The baker wants to analyze the effect of different settings of his oven to the quality of the resulting bread by conducting several experiments. === Target Values === We define the targets of experiments (here to improve the quality of the bread) as '''target values'''. === Input Parameters === All sources of influence on the target values are referred to as '''factors'''. Three different groups of factors are distinguished: # ''noise factors'': These factors cannot be controlled or controlling these factors is too expensive. As an example, the temperature and humidity in the bakery depends on the season and weather and cannot be controlled. # ''control factors'': These factors can be controlled. However, their influence on the target value is not of interest and thus, these factors are set constant. For example, the baker wants to leave his recipe for the bread unchanged. # ''signal factors'': These factors can be controlled. Their influence is of interest and their values are modified in the experiments. DoE is important when we have to analyze a process with multiple signal factors, in order to determine their effect on the target value(s). '''''Note:''' In the following, we will only consider signal factors. For simplicity, they are referred to as factors.'' === Factor Levels === For each factor, we may want to analyze different values. For example, we want to analyze an oven temperature of 185, 190, 195, and 200^oC and a baking time of 45, 50, 55 and 60 minutes. These different values are referred to as ''factor levels''. === Experiment === One experiment is one combination of different factor levels and the corresponding target values for the experiment. For example, one experiment may be a temperature of 190^oC and a baking time of 60 min. One experiment is also referred to as one '''factor level combination'''. === DoE Plan === The DoE plan defines which experiments are to be conducted and in which sequence they are conducted. The sequence may be important as environmental conditions like temperature may effect the target values as well as hysteresis effects. DoE plans differ in number of total experiments and the order of the experiments. The number of experiments strongly influences the information gain and the trust in the experiments. As references for DoE plans we recommend [ [[#klepp | 1]], [[#wikidoe | 2]] ]. == DoE Plans == A DoE plan can be considered as a set of rules describing how to choose factors, the number of factor levels, factor level values or value distributions, etc.. In the following, two different DoE plans are outlined. === Full Factorial === [[Image:DoEFullFactorial.png|frame|right|A two factor Full Factorial plan. Each square represents one possible experiment. The "X" denote the actual experiments that will be scheduled.]] For given numbers of factor levels for each variable, a limited number of different experiments can be conducted. A DoE plan with all possible experiments is referred to as '''Full Factorial''' plan: The number of factor levels may vary for the factors. All other plans use only a subset of all possible experiments. === Latin Hypercube === [[Image:DoELatinHypercube.png|frame|right|A two factor Latin Hypercube plan. Each square represents one possible experiment. The "X" denote the actual experiments that will be scheduled.]] Compared to the Full Factorial plan, the Latin Hypercube (LHC) sampling dramatically reduces the number of experiments (see e.g. [ [[#wikilhc | 3]] ]). So it is most useful for expensive experiments, whether they be money or time intensive. Latin Hypercube requires the same number of factor levels for all factors. The number of experiments of a LHC plan is equal to the number of factor levels and is independent on the number of factors. This makes it very scalable (O(1)) in respect of number of factors. The philosophy of LHC is to use every factor level exactly once. The figure on the right demonstrates a possible plan for 4 factor levels. As each factor level is only used once, each row and column in the figure must contain exactly one cross. Thus, LHC guaranties that for each factor, the entire range of factor levels is used. == Common Settings for all DoE Plans == The following list explains common settings for all DoE plans. === Number of Iterations === The testing of a set of experiments that a DoE plan proposes is referred to as one ''iteration''. If we would schedule three ''iterations'', each experiment (i.e. a certain factor level combination) in the set is tested exactly three times. Using more than one iteration is only necessary if the system to analyze is noisy (i.e. the target values are noisy), may contain a drift while testing, or produces hysteresis. === Random Scheduling === [[Image:DoERandomBlock.png|thumb|250px|right|Four different scheduling plans of six experiments resulting from DoE plan with three experiments and two iterations. The small double-bordered boxes outline the blocks.]] Without ''random scheduling'', the experiments are tested in a fixed order. With ''randomization'' activated, a random sequence for the experiment is set up. To what extend the randomization occurs depends on whether ''block building'' is active or not. ''Random scheduling'' may help to analyze effects like hysteresis, i.e. the previous experiment effects the outcome of the current experiment. If we run multiple iterations, the effect of hysteresis decreases because of statistical reasons. === Block Building === If ''block building'' is activated, all experiments of one iteration are tested. Then, all experiments of the next iteration are tested. If ''block building'' is '''de'''activated, experiments of different iterations may follow each other. ''Block building'', like ''random scheduling'', may reduce the effect that may occur because of the order in which the experiments get scheduled. While ''random scheduling'' may reduce the effect of subsequent experiments, activating ''block building'' may reduce the effect caused by external (long term) influences. These influences can be quality of the used materials, which may vary over time or depend on the supplier, human interaction with the machines or the accuracy of machines of the same type used for the experiments. == DoE in OpenDino == A description for DoE in OpenDino can be found in the module documentation (see [[Documentation/Modules/DoePlanner]]). == References == <span id="klepp">1</span> Wilhelm Kleppmann, Taschenbuch Versuchsplanung (4. Auflage) - Produkte und Prozesse optimieren, Carl Hanser Verlag Muenchen Wien, 2006 <span id="wikidoe">2</span> http://en.wikipedia.org/wiki/Design_of_experiments <span id="wikilhc">3</span> http://en.wikipedia.org/wiki/Latin_hypercube 0 47 120 57 2013-09-12T20:15:44Z Admin 1 wikitext text/x-wiki == Download Software == . '''!!!!!!!!!!!!!!!!!!!!!!!''' '''CURRENTLY NOT AVAILABLE''' '''!!!!!!!!!!!!!!!!!!!!!!!''' . == Download Source Code == . '''!!!!!!!!!!!!!!!!!!!!!!!''' '''CURRENTLY NOT AVAILABLE''' '''!!!!!!!!!!!!!!!!!!!!!!!''' . The software is version controlled using a Subversion (SVN) repository. In the SVN repository, a "trunk" exist and "branches" might be added. "trunk" contains the main development and should always at least compile and be executable. "branches" are copies of the "trunk" for temporary modifications (see the [http://subversion.tigris.org/ subversion homepage]) and should not be downloaded. Download the software with shell command: <pre> $ svn checkout {ToDo:Link to SVN}</pre> Downloading requires a [http://subversion.tigris.org/ subversion client] or an appropriate plug-in for your IDE. 130 120 2013-09-27T19:49:12Z Dirk 2 /* Download Source Code */ wikitext text/x-wiki == Download Software == . '''!!!!!!!!!!!!!!!!!!!!!!!''' '''CURRENTLY NOT AVAILABLE''' '''!!!!!!!!!!!!!!!!!!!!!!!''' . == Download Source Code == Source code is located at https://sourceforge.net/p/opendino/code The software is version controlled using a Subversion (SVN) repository. In the SVN repository, a "trunk" exist and "branches" might be added. "trunk" contains the main development and should always at least compile and be executable. "branches" are copies of the "trunk" for temporary modifications (see the [http://subversion.tigris.org/ subversion homepage]) and should not be downloaded. Download the software with shell command: <pre> $ svn checkout svn://svn.code.sf.net/p/opendino/code/trunk</pre> Downloading requires a [http://subversion.tigris.org/ subversion client] or an appropriate plug-in for your IDE. 140 130 2014-03-19T20:12:31Z Admin 1 /* Download Source Code */ wikitext text/x-wiki == Download Software == . '''!!!!!!!!!!!!!!!!!!!!!!!''' '''CURRENTLY NOT AVAILABLE''' '''!!!!!!!!!!!!!!!!!!!!!!!''' . == Download Source Code == Source code is located at https://sourceforge.net/p/opendino/code The software is version controlled using a Subversion (SVN) repository. In the SVN repository, a "trunk" exist and "branches" might be added. "trunk" contains the main development and should always at least compile and be executable. "branches" are copies of the "trunk" for temporary modifications (see the [http://subversion.tigris.org/ subversion homepage]) and should not be downloaded. Download the software with shell command: <pre> $ svn checkout svn://svn.code.sf.net/p/opendino/code/trunk</pre> Downloading requires a [http://subversion.apache.org/ subversion client] or an appropriate plug-in for your IDE. 141 140 2014-03-19T20:17:55Z Admin 1 /* Download Source Code */ wikitext text/x-wiki == Download Software == . '''!!!!!!!!!!!!!!!!!!!!!!!''' '''CURRENTLY NOT AVAILABLE''' '''!!!!!!!!!!!!!!!!!!!!!!!''' . == Download Source Code == Source code is located at https://sourceforge.net/p/opendino/code The software is version controlled using a Subversion (SVN) repository. Download the software with shell command: <pre> $ svn checkout svn://svn.code.sf.net/p/opendino/code/ opendino-code</pre> In the SVN repository, a "trunk" exist and "branches" might be added. "trunk" contains the main development and should always at least compile and be executable. "branches" are copies of the "trunk" for temporary modifications (see the [http://subversion.apache.org/ subversion homepage]) and should not be downloaded. Downloading requires a [http://subversion.apache.org/ subversion client] or an appropriate plug-in for your IDE. 142 141 2014-03-19T21:42:17Z Admin 1 /* Download Software */ wikitext text/x-wiki == Download Software == The executable jar file with source code is given in the file 19.3.2014 [[Media:opendino_0.1.jar | opendino_0.1.jar]] == Download Source Code == Source code is located at https://sourceforge.net/p/opendino/code The software is version controlled using a Subversion (SVN) repository. Download the software with shell command: <pre> $ svn checkout svn://svn.code.sf.net/p/opendino/code/ opendino-code</pre> In the SVN repository, a "trunk" exist and "branches" might be added. "trunk" contains the main development and should always at least compile and be executable. "branches" are copies of the "trunk" for temporary modifications (see the [http://subversion.apache.org/ subversion homepage]) and should not be downloaded. Downloading requires a [http://subversion.apache.org/ subversion client] or an appropriate plug-in for your IDE. 143 142 2014-03-19T21:42:56Z Admin 1 /* Download Software */ wikitext text/x-wiki == Download Software == The executable jar file with source code is given in the file || Date || File || || 19.3.2014 || [[Media:opendino_0.1.jar | opendino_0.1.jar]] || == Download Source Code == Source code is located at https://sourceforge.net/p/opendino/code The software is version controlled using a Subversion (SVN) repository. Download the software with shell command: <pre> $ svn checkout svn://svn.code.sf.net/p/opendino/code/ opendino-code</pre> In the SVN repository, a "trunk" exist and "branches" might be added. "trunk" contains the main development and should always at least compile and be executable. "branches" are copies of the "trunk" for temporary modifications (see the [http://subversion.apache.org/ subversion homepage]) and should not be downloaded. Downloading requires a [http://subversion.apache.org/ subversion client] or an appropriate plug-in for your IDE. 144 143 2014-03-19T21:46:30Z Admin 1 /* Download Software */ wikitext text/x-wiki == Download Software == The executable jar file with source code is given in the file {| border="1" cellpadding="10" cellspacing="0" !Date !File |- | 19.3.2014 | [[Media:opendino_0.1.jar | opendino_0.1.jar]] |} == Download Source Code == Source code is located at https://sourceforge.net/p/opendino/code The software is version controlled using a Subversion (SVN) repository. Download the software with shell command: <pre> $ svn checkout svn://svn.code.sf.net/p/opendino/code/ opendino-code</pre> In the SVN repository, a "trunk" exist and "branches" might be added. "trunk" contains the main development and should always at least compile and be executable. "branches" are copies of the "trunk" for temporary modifications (see the [http://subversion.apache.org/ subversion homepage]) and should not be downloaded. Downloading requires a [http://subversion.apache.org/ subversion client] or an appropriate plug-in for your IDE. 145 144 2014-03-19T21:48:55Z Admin 1 /* Download Source Code */ wikitext text/x-wiki == Download Software == The executable jar file with source code is given in the file {| border="1" cellpadding="10" cellspacing="0" !Date !File |- | 19.3.2014 | [[Media:opendino_0.1.jar | opendino_0.1.jar]] |} == Download Source Code == The software is version controlled using a Subversion (SVN) repository. Source code is located at https://sourceforge.net/p/opendino/code The URL specifies also the download command. In the SVN repository, a "trunk" exist and "branches" might be added. "trunk" contains the main development and should always at least compile and be executable. "branches" are copies of the "trunk" for temporary modifications (see the [http://subversion.apache.org/ subversion homepage]) and should not be downloaded. Downloading requires a [http://subversion.apache.org/ subversion client] or an appropriate plug-in for your IDE. 0 25 121 31 2013-09-12T20:16:44Z Admin 1 wikitext text/x-wiki =Optimization= == Introduction == Optimization searches for the best solution '''x'''* to a problem and can be defined as '''x'''* = argmin (''f''('''x''')) where ''f'' is the function to be optimized (the objective function) and '''x''' are the design variables for which optimal settings have to be found. This definition can be extended to multiple objectives '''f''' and by constraints. == Some Important Expressions == === Manual vs. Automated Optimization === Optimization is an everyday task. For example, searching the fastest way to work or home is an optimization problem. We speak about ''automated'' optimization, if a computer algorithm solves the problem in an automated fashion, i.e. without user interaction. === Objective Function === Optimization typically searches for the optimal solution to a problem. For automated optimization, the problem must be encoded in a mathematical function ''f'', which has to be either minimized or maximized. In OpenDINO, only minimization is considered as maximization can be expressed as: max(f) = - min(-f) === Design Variables === The optimal solution is searched by modifying the design variables '''x'''. The objective function depends on the design variables: f = f('''x'''). === Multiple Objectives === If multiple objectives '''f''' should be optimized, then a multi-objective optimization problem has to be solved. Some optimization algorithms search concurrently for multiple compromise solutions for the objectives (Pareto optimization) or a single compromise solution, defined as a weighed sum of all objectives. === Constraints === While the optimization algorithm tries to minimize all objectives, constraints simply have to be fulfilled. For example, the maximal stress in a truss should not exceed a certain limit. If the stress is below the limit, no advantage is gained. If the stress is above the limit, the solution is typically constrained by a penalty value, which increases with increasing constraint violation. === Direct vs. Indirect Search === In OpenDINO, we implement optimization algorithms that search a problem in an iterative fashion, i.e. by computing several different solutions to the problem. The best solution is returned. This iterative search can be either direct or indirect: '''Direct''' search uses only direct information (i.e. the objective and constraint value(s). '''Indirect''' algorithms use indirect information (i.e. gradient and/or higher order derivative information of the objective(s) and constraint(s)). === Stochastic vs. Deterministic Algorithms === While '''stochastic''' algorithms such as Evolutionary Algorithms and Particle Swarm use random values in their search method, '''deterministic''' algorithms like the Simplex Method or gradient based search do not. 157 121 2014-03-19T22:09:15Z Admin 1 wikitext text/x-wiki =Optimization= == Introduction == Optimization searches for the best solution '''x'''* to a problem and can be defined as '''x'''* = argmin (''f''('''x''')) where ''f'' is the function to be optimized (the objective function) and '''x''' are the design variables for which optimal settings have to be found. This definition can be extended to multiple objectives '''f''' and by constraints. == Some Important Expressions == === Manual vs. Automated Optimization === Optimization is an everyday task. For example, searching the fastest way to work or home is an optimization problem. We speak about ''automated'' optimization, if a computer algorithm solves the problem in an automated fashion, i.e. without user interaction. === Objective Function === Optimization typically searches for the optimal solution to a problem. For automated optimization, the problem must be encoded in a mathematical function ''f'', which has to be either minimized or maximized. In OpenDino, only minimization is considered as maximization can be expressed as: max(f) = - min(-f) === Design Variables === The optimal solution is searched by modifying the design variables '''x'''. The objective function depends on the design variables: f = f('''x'''). === Multiple Objectives === If multiple objectives '''f''' should be optimized, then a multi-objective optimization problem has to be solved. Some optimization algorithms search concurrently for multiple compromise solutions for the objectives (Pareto optimization) or a single compromise solution, defined as a weighed sum of all objectives. === Constraints === While the optimization algorithm tries to minimize all objectives, constraints simply have to be fulfilled. For example, the maximal stress in a truss should not exceed a certain limit. If the stress is below the limit, no advantage is gained. If the stress is above the limit, the solution is typically constrained by a penalty value, which increases with increasing constraint violation. === Direct vs. Indirect Search === In OpenDino, we implement optimization algorithms that search a problem in an iterative fashion, i.e. by computing several different solutions to the problem. The best solution is returned. This iterative search can be either direct or indirect: '''Direct''' search uses only direct information (i.e. the objective and constraint value(s). '''Indirect''' algorithms use indirect information (i.e. gradient and/or higher order derivative information of the objective(s) and constraint(s)). === Stochastic vs. Deterministic Algorithms === While '''stochastic''' algorithms such as Evolutionary Algorithms and Particle Swarm use random values in their search method, '''deterministic''' algorithms like the Simplex Method or gradient based search do not. 0 40 122 99 2013-09-12T20:19:00Z Admin 1 wikitext text/x-wiki == Download == The compiled software can be downloaded from [[Download]] page. As the software is written in Java, the compiled code runs on most platforms. The software consists of a single jar file <tt>opendino.jar</tt>. == Start == Start OpenDINO with either: * double clicking on the jar (this is simple, however, not activated on all plattforms and console output may not be seen). * open a Linux shell or Windows Command Line and enter one of the following two command in the same directory as file <tt>opendino.jar</tt> was downloaded (Windows often requires the latter command). <pre>$ java -jar opendino.jar </pre> <pre>$ java -classpath opendino.jar org.opendino.core.OpenDINO</pre> * to see additional command line options enter <pre>$ java -jar opendino.jar -help </pre> == Writing a Shell Script == The script assumes an OpenDINO archive file <tt>opendino.jar</tt>. This filename can be replaced to match the actual name or by a filename with absolute path. In Windows, create a file <tt>opendino.bat</tt> with the following content: java -cp opendino.jar org/opendino/core/OpenDINO %* In Linux, create a file <tt>opendino.sh</tt> with the following content: #!/bin/sh java -classpath opendino.jar org.opendino.core.OpenDINO $* To make the file executable enter in the shell: chmod u+x opendino.sh 128 122 2013-09-27T18:12:16Z Dirk 2 /* Writing a Shell Script */ wikitext text/x-wiki == Download == The compiled software can be downloaded from [[Download]] page. As the software is written in Java, the compiled code runs on most platforms. The software consists of a single jar file <tt>opendino.jar</tt>. == Start == Start OpenDINO with either: * double clicking on the jar (this is simple, however, not activated on all plattforms and console output may not be seen). * open a Linux shell or Windows Command Line and enter one of the following two command in the same directory as file <tt>opendino.jar</tt> was downloaded (Windows often requires the latter command). <pre>$ java -jar opendino.jar </pre> <pre>$ java -classpath opendino.jar org.opendino.core.OpenDINO</pre> * to see additional command line options enter <pre>$ java -jar opendino.jar -help </pre> == Writing a Shell Script == The script assumes an OpenDINO archive file <tt>opendino.jar</tt>. This filename can be replaced to match the actual name or by a filename with absolute path. For '''Windows''', create a file <tt>opendino.bat</tt> with the following content: java -cp opendino.jar org/opendino/core/OpenDINO %* For '''Linux''', create a file <tt>opendino.sh</tt> with the following content: #!/bin/sh java -classpath opendino.jar org.opendino.core.OpenDINO $* To make the file executable enter in the shell: chmod u+x opendino.sh 147 128 2014-03-19T22:02:57Z Admin 1 /* Start */ wikitext text/x-wiki == Download == The compiled software can be downloaded from [[Download]] page. As the software is written in Java, the compiled code runs on most platforms. The software consists of a single jar file <tt>opendino.jar</tt>. == Start == Start OpenDino with either: * double clicking on the jar (this is simple, however, not activated on all plattforms and console output may not be seen). * open a Linux shell or Windows Command Line and enter one of the following two command in the same directory as file <tt>opendino.jar</tt> was downloaded (Windows often requires the latter command). <pre>$ java -jar opendino.jar </pre> <pre>$ java -classpath opendino.jar org.opendino.core.OpenDINO</pre> * to see additional command line options enter <pre>$ java -jar opendino.jar -help </pre> == Writing a Shell Script == The script assumes an OpenDINO archive file <tt>opendino.jar</tt>. This filename can be replaced to match the actual name or by a filename with absolute path. For '''Windows''', create a file <tt>opendino.bat</tt> with the following content: java -cp opendino.jar org/opendino/core/OpenDINO %* For '''Linux''', create a file <tt>opendino.sh</tt> with the following content: #!/bin/sh java -classpath opendino.jar org.opendino.core.OpenDINO $* To make the file executable enter in the shell: chmod u+x opendino.sh 148 147 2014-03-19T22:03:30Z Admin 1 /* Start */ wikitext text/x-wiki == Download == The compiled software can be downloaded from [[Download]] page. As the software is written in Java, the compiled code runs on most platforms. The software consists of a single jar file <tt>opendino.jar</tt>. == Start == Start OpenDino with either: * double clicking on the jar (this is simple, however, not activated on all plattforms and console output may not be seen). * open a Linux shell or Windows Command Line and enter one of the following two command in the same directory as file <tt>opendino.jar</tt> was downloaded (Windows often requires the latter command). <pre>$ java -jar opendino.jar </pre> <pre>$ java -classpath opendino.jar org.opendino.core.OpenDino</pre> * to see additional command line options enter <pre>$ java -jar opendino.jar -help </pre> == Writing a Shell Script == The script assumes an OpenDINO archive file <tt>opendino.jar</tt>. This filename can be replaced to match the actual name or by a filename with absolute path. For '''Windows''', create a file <tt>opendino.bat</tt> with the following content: java -cp opendino.jar org/opendino/core/OpenDINO %* For '''Linux''', create a file <tt>opendino.sh</tt> with the following content: #!/bin/sh java -classpath opendino.jar org.opendino.core.OpenDINO $* To make the file executable enter in the shell: chmod u+x opendino.sh 0 38 123 92 2013-09-12T20:20:31Z Admin 1 wikitext text/x-wiki ==Basics== The basic element of each OpenDINO optimization or learning environment is still the <code>Module</code>. Each optimization problem, each optimization algorithm and each learning algorithm is a module. A class that is used as a module must implement the interface <code>org.opendino.core.modules.IModule</code> (see [[Documentation/IModule | IModule]]). The whole structure of modules in OpenDINO is based on interfaces. The reason for this is that classes that are used as <code>Modules</code> may be part of a class hierarchy and thus they cannot inherit from a basic module class. There are <code>Modules</code> that can be run, e.g. optimization algorithms. All these modules implement the interface <code>org.opendino.core.modules.IRunnable</code>. Each optimization setup consists of at least two linked <code>Modules</code>: a problem and an optimizer. The interfaces for these modules are <code>org.opendino.core.modules.optimization.IEvaluable</code> and <code>IEvaluator</code>, respecively. The corresponding pair for a learning task is <code>org.opendino.core.modules.learning.IDataSource</code> and <code>IDataSink</code>. Modules can be linked between other modules. E.g. the protocoller is a <code>Module</code> that you can link between an optimizer and a problem. In such a case, all <code>Modules</code> except the optimizer must implement the interface <code>Evaluable</code> and all modules except the problem must implement the interface <code>IEvaluator</code>. This means that the modules form a chain that looks like this (here, two intermediate modules are shown): <pre> [IEvaluator] | [IEvaluable and IEvaluator] | [IEvaluable and IEvaluator] | [IEvaluable] </pre> where the topmost evaluator is the optimizer and the bottommost evaluable is the optimization problem. The meaning of this picture is that the optimizer produces points and sends them through the chain to the problem. The problem evaluates the points, assigning each point its objective value(s). These are read by the optimizer which then tries to create better points, etc. The same kind of interaction chain is possible for learners and data sources. But there, the information flow is mainly in unidirectional: from the data source to the data sink. ==The Interfaces== ===IModule=== This is the basic interface implemented by all modules. It contains methods for the initialisation and checking of the module and for the management of the options of the module. ===IRunnable=== This interfaces is implemented by all modules that can be run. When a module is run, it executes its optimization algorithm. In the future this could be any kind of algorithm. The interface contains methods to start and stop the execution of the module. ===IEvaluable=== Every module that represents an optimization problem implements the interface IEvaluable. This means that the module can evaluate a given solution. To that end, it looks at the design variables of a solution object it gets from an optimizer and sets the objective value(s) of that object accordingly. If a module is linked before a problem module, it must implement IEvaluable and delegate the evaluation of the solutions to the problem module. Thus, the optmimizer doesn't know if the module right after it is the problem itself or an intermediate module, it just calls the evaluate method of its successor module. IEvaluable contains methods to evaluate one solution or an array of solutions and a method to get the properties of the problem. ===IEvaluator=== A module that can call an evaluable to evaluate solutions implements the interface IEvaluator. Normally, an evaluator is an optimizer module, but any intermediate module between the optimizer and the problem must implement this interface as well. Otherwise, it wouldn't be able to call the problem to evaluate the solutions. IEvaluator contains methods to get and set the references to the evaluables and to check if these links are OK. ===IDataSource=== A module that provides data. This can be a file reader, the protocoller, or other modules that can produce or store data. The getData() method is the most important one. ===IDataSink=== A module implementing this interface represents a learner. It is linked with a data source and processes the given data. Very different kinds of processing are possible. A data viewer can just display the data, a neural network can learn a function from the data or a statistics module can compute some statistics on the data etc. 152 123 2014-03-19T22:06:03Z Admin 1 wikitext text/x-wiki ==Basics== The basic element of each OpenDino optimization or learning environment is still the <code>Module</code>. Each optimization problem, each optimization algorithm and each learning algorithm is a module. A class that is used as a module must implement the interface <code>org.opendino.core.modules.IModule</code> (see [[Documentation/IModule | IModule]]). The whole structure of modules in OpenDino is based on interfaces. The reason for this is that classes that are used as <code>Modules</code> may be part of a class hierarchy and thus they cannot inherit from a basic module class. There are <code>Modules</code> that can be run, e.g. optimization algorithms. All these modules implement the interface <code>org.opendino.core.modules.IRunnable</code>. Each optimization setup consists of at least two linked <code>Modules</code>: a problem and an optimizer. The interfaces for these modules are <code>org.opendino.core.modules.optimization.IEvaluable</code> and <code>IEvaluator</code>, respecively. The corresponding pair for a learning task is <code>org.opendino.core.modules.learning.IDataSource</code> and <code>IDataSink</code>. Modules can be linked between other modules. E.g. the protocoller is a <code>Module</code> that you can link between an optimizer and a problem. In such a case, all <code>Modules</code> except the optimizer must implement the interface <code>Evaluable</code> and all modules except the problem must implement the interface <code>IEvaluator</code>. This means that the modules form a chain that looks like this (here, two intermediate modules are shown): <pre> [IEvaluator] | [IEvaluable and IEvaluator] | [IEvaluable and IEvaluator] | [IEvaluable] </pre> where the topmost evaluator is the optimizer and the bottommost evaluable is the optimization problem. The meaning of this picture is that the optimizer produces points and sends them through the chain to the problem. The problem evaluates the points, assigning each point its objective value(s). These are read by the optimizer which then tries to create better points, etc. The same kind of interaction chain is possible for learners and data sources. But there, the information flow is mainly in unidirectional: from the data source to the data sink. ==The Interfaces== ===IModule=== This is the basic interface implemented by all modules. It contains methods for the initialisation and checking of the module and for the management of the options of the module. ===IRunnable=== This interfaces is implemented by all modules that can be run. When a module is run, it executes its optimization algorithm. In the future this could be any kind of algorithm. The interface contains methods to start and stop the execution of the module. ===IEvaluable=== Every module that represents an optimization problem implements the interface IEvaluable. This means that the module can evaluate a given solution. To that end, it looks at the design variables of a solution object it gets from an optimizer and sets the objective value(s) of that object accordingly. If a module is linked before a problem module, it must implement IEvaluable and delegate the evaluation of the solutions to the problem module. Thus, the optmimizer doesn't know if the module right after it is the problem itself or an intermediate module, it just calls the evaluate method of its successor module. IEvaluable contains methods to evaluate one solution or an array of solutions and a method to get the properties of the problem. ===IEvaluator=== A module that can call an evaluable to evaluate solutions implements the interface IEvaluator. Normally, an evaluator is an optimizer module, but any intermediate module between the optimizer and the problem must implement this interface as well. Otherwise, it wouldn't be able to call the problem to evaluate the solutions. IEvaluator contains methods to get and set the references to the evaluables and to check if these links are OK. ===IDataSource=== A module that provides data. This can be a file reader, the protocoller, or other modules that can produce or store data. The getData() method is the most important one. ===IDataSink=== A module implementing this interface represents a learner. It is linked with a data source and processes the given data. Very different kinds of processing are possible. A data viewer can just display the data, a neural network can learn a function from the data or a statistics module can compute some statistics on the data etc. 0 28 124 103 2013-09-12T20:21:51Z Admin 1 wikitext text/x-wiki Check the [[Documentation/Software/Requirements | software requirements]] first! Then [[Documentation/Download/SVN | download]] the source code. == Using an IDE == OpenDINO is currently developed with [http://www.netbeans.org/ NetBeans], as many windows are generated with the Swing framework. However, other platforms such as Eclipse [http://www.eclipse.org/ Eclipse] can also be used. Compiling and executing the software in a shell is also supported using <code>Makefile</code>s as build system. == Compiling in a Shell == Two platforms are currently tested: <ul> <li><b>Linux: </b> A typical standard implementation of Linux with a Java JDK should contain all required programs for compiling and running OpenDINO. </li> <li><b>Windows: </b> [http://www.cygwin.com/ Cygwin (R)] is used to compile OpenDINO on Windows(R) platforms. </li> </ul> Compiling on other platforms has not been tested. === Creating the Makefile === The Makefile is automatically generated by the script <tt>createMakefile</tt>. In a shell, go to the subfolder <tt>opendino/trunk</tt> and execute: <pre>$ ./createMakefile</pre> Enter <pre>$ make</pre> to list the possible actions. === Compiling the Source Code & Executing OpenDINO === For Linux systems enter <pre>$ make javac $ make gui</pre> to compile and start OpenDINO in GUI mode. For Windows systems enter <pre>$ make javac_cygwin $ make gui</pre> 156 124 2014-03-19T22:08:10Z Admin 1 wikitext text/x-wiki Check the [[Documentation/Software/Requirements | software requirements]] first! Then [[Documentation/Download/SVN | download]] the source code. == Using an IDE == OpenDino is currently developed with [http://www.netbeans.org/ NetBeans], as many windows are generated with the Swing framework. However, other platforms such as Eclipse [http://www.eclipse.org/ Eclipse] can also be used. Compiling and executing the software in a shell is also supported using <code>Makefile</code>s as build system. == Compiling in a Shell == Two platforms are currently tested: <ul> <li><b>Linux: </b> A typical standard implementation of Linux with a Java JDK should contain all required programs for compiling and running OpenDino. </li> <li><b>Windows: </b> [http://www.cygwin.com/ Cygwin (R)] is used to compile OpenDino on Windows(R) platforms. </li> </ul> Compiling on other platforms has not been tested. === Creating the Makefile === The Makefile is automatically generated by the script <tt>createMakefile</tt>. In a shell, go to the subfolder <tt>opendino/trunk</tt> and execute: <pre>$ ./createMakefile</pre> Enter <pre>$ make</pre> to list the possible actions. === Compiling the Source Code & Executing OpenDino === For Linux systems enter <pre>$ make javac $ make gui</pre> to compile and start OpenDino in GUI mode. For Windows systems enter <pre>$ make javac_cygwin $ make gui</pre> 0 36 125 85 2013-09-12T20:22:18Z Admin 1 wikitext text/x-wiki =Interface <tt>IModule</tt>= All <tt>Modules</tt> in OpenDINO must implement the Interface <tt> IModule</tt>. The interface contains a set of methods. The purpose and the functionality of these methods is described in the following sections. Furthermore, the <tt>Modules</tt> must have a class <tt>Options</tt> that comprises all user settings as simple types (<tt>boolean</tt>, <tt>long</tt>, <tt>double</tt>, <tt>String</tt>) or vectors/arrays of those types. The options are automatically read using Java Reflection API. It is essential for a correct program execution to ensure that the guidelines are exactly followed by the <tt>Modules</tt> programmers. == Method <tt>Options getOptions()</tt> == # Functionality #* returns the current <tt>Options</tt> class. #* ensure that cloned <tt>Options</tt> are returned! # Objectives #* returning a clone of the <tt>Options</tt> ensures that changing <tt>Options</tt> outside the <tt>Module</tt> has no impact. # Sample Code <pre> public Options getOptions() { return (Options) options.clone(); } </pre> == Method <tt>void setOptions(Options o)</tt> == # Functionality #* sets the <tt>Options</tt> for a <tt>Module</tt> #* ensure that <tt>Options</tt> are cloned before they are set! # Objectives #* setting a clone of the <tt>Options</tt> ensures that changing <tt>Options</tt> outside the <tt>Modules</tt> has no impact. # Sample Code <pre> public void setOptions(Options o) { options = (Options) o.clone(); } </pre> == Method <tt>String check() </tt> == # Functionality #* check, if this <tt>Modules</tt> is set up correctly, i.e. checks if #** the <tt>Options</tt> are correct? #** all required <tt>Connections</tt> of the <tt>Modules</tt> are available (e.g. an optimization algorithm may require one connection to a problem) #** the settings (e.g. Options) agree with the properties of connected <tt>Modules</tt>? #* checking requires several steps: #*# if the <tt>Modules</tt> is connected to other <tt>Modules</tt>, it should first #*#* call <tt>check()</tt> of the connected <tt>Modules</tt> and #*#* return a message, if any connected <tt>Modules</tt>’s check is unsuccessful (i.e. a non-empty string is returned). #*# if checking the connected <tt>Modules</tt> was successful, the <tt>Modules</tt> should check itself and return a non-empty string if checking fails. # Properties #* checks are usually fast # Return Value #* empty string “” if successful, else a message #Sample Code for Optimization: <pre> public String check(){ s = ""; // 1. check connected modules for (Object o: evaluables) { String so=((IModule)o).check(); if (so.length > 0){ s += “checking connected module with ID “ + (IModule o).getID() + “ failed with message: \\n” + so; } } if (s.length > 0){ return “checking connected modules failed: \\n” + s; // 2. check this module, return String if not successful if (opt.verbose > 3) s+= "Option verbose must be between 0 and 3, but is set to " + opt.verbose + "\\n"; // … return s; } </pre> == Method <tt>String init(long index)</tt> == Currently the <tt>index</tt> is not used! # Functionality #* initialize <tt>Modules</tt> such that executing optimizations or learning processes is possible. #* Initialization requires several steps: #*# check if the argument (index) has changed compared to the time of the last check (see also example below). If the argument has not changed, the system has not changed and a new initialization is not necessary. Thus, return the message of the previous check and do no further checking. #*# If the <tt>Modules</tt> is connected to other Modules, it should first #*#* call the <tt>init()</tt> of the connected <tt>Modules</tt> and #*#* return a message, if any connected <tt>Modules</tt> fails to initialize #*# If the initialization of the connected <tt>Modules</tt> is successful, it should then get the properties of the connected <tt>Modules</tt> #*#* return a message, if any connected <tt>Modules</tt> fails to return properties. #*# Initialize itself and return a string if initialization fails. # Objectives #* initialization should never lead to exceptions. #* It must not call <tt>check()</tt>! # Properties #* the <tt>init()</tt> method is the only method of <tt>IModule</tt> that may require CPU time (e.g. for loading a large data source). Thus this method should not be called too often. # Advanced Features #* the<tt>Modules</tt> should check if initialization is necessary. Typically initialization is necessary when #** the <tt>Options</tt> of the<tt>Modules</tt> are changed #** the connections of the<tt>Modules</tt> changed #** the properties of the connected <i>Modules</i> changed #* if nothing changed, it should not initialize in order to save computer resources # Return Value #* empty string “” if successful, else a message # Sample Code for Optimization: <pre> public string init(long init_id){ s = ""; if (this.init_id == init_id){ return [the message of the last initialization]; this.init_id = init_id; for (Object o: evaluables) { String so=((IModule)o).init(init_id); if (so.length > 0){ s += “initializing connected module with ID “ + (IModule o).getID() + “ failed with message: \\n” + so; } } if (s.length > 0){ return “initializing connected modules failed: \\n” + s; // initialize this module, return String if not successful // … return s; } </pre> '''Summary''' Properties of a <tt>Module</tt> should only change when the Method <tt>init()</tt> is called. This guarantees that <tt>Modules</tt> do not change while they are checked or other <tt>Modules</tt> are running! == Method <tt>int getID()</tt> == # Functionality #* gets the ID for this <tt>Module</tt>. # Objectives #* the ID is important for debugging, e.g. <tt>Modules</tt> can identify to which other <tt>Modules</tt> they are connected. == Method <tt>void setID(int id)</tt> == # Functionality #* sets the ID for this <tt>Module</tt>. # Objectives #* IDs should be set at the time of instantiation and should not be modified. #* the ID is important for debugging, e.g. <tt>Modules</tt> can identify to which other <tt>Modules</tt> they are connected. == Method <tt>String getInfo()</tt> == # Functionality #* Returns a String in HTML or plain text, describing the module #* A<tt>Modules</tt> such as an optimization algorithm should return the problem properties when it this<tt>Modules</tt> is called. # Objectives #* get information about<tt>Modules</tt> properties for checking or debugging user settings 153 125 2014-03-19T22:06:25Z Admin 1 wikitext text/x-wiki =Interface <tt>IModule</tt>= All <tt>Modules</tt> in OpenDino must implement the Interface <tt> IModule</tt>. The interface contains a set of methods. The purpose and the functionality of these methods is described in the following sections. Furthermore, the <tt>Modules</tt> must have a class <tt>Options</tt> that comprises all user settings as simple types (<tt>boolean</tt>, <tt>long</tt>, <tt>double</tt>, <tt>String</tt>) or vectors/arrays of those types. The options are automatically read using Java Reflection API. It is essential for a correct program execution to ensure that the guidelines are exactly followed by the <tt>Modules</tt> programmers. == Method <tt>Options getOptions()</tt> == # Functionality #* returns the current <tt>Options</tt> class. #* ensure that cloned <tt>Options</tt> are returned! # Objectives #* returning a clone of the <tt>Options</tt> ensures that changing <tt>Options</tt> outside the <tt>Module</tt> has no impact. # Sample Code <pre> public Options getOptions() { return (Options) options.clone(); } </pre> == Method <tt>void setOptions(Options o)</tt> == # Functionality #* sets the <tt>Options</tt> for a <tt>Module</tt> #* ensure that <tt>Options</tt> are cloned before they are set! # Objectives #* setting a clone of the <tt>Options</tt> ensures that changing <tt>Options</tt> outside the <tt>Modules</tt> has no impact. # Sample Code <pre> public void setOptions(Options o) { options = (Options) o.clone(); } </pre> == Method <tt>String check() </tt> == # Functionality #* check, if this <tt>Modules</tt> is set up correctly, i.e. checks if #** the <tt>Options</tt> are correct? #** all required <tt>Connections</tt> of the <tt>Modules</tt> are available (e.g. an optimization algorithm may require one connection to a problem) #** the settings (e.g. Options) agree with the properties of connected <tt>Modules</tt>? #* checking requires several steps: #*# if the <tt>Modules</tt> is connected to other <tt>Modules</tt>, it should first #*#* call <tt>check()</tt> of the connected <tt>Modules</tt> and #*#* return a message, if any connected <tt>Modules</tt>’s check is unsuccessful (i.e. a non-empty string is returned). #*# if checking the connected <tt>Modules</tt> was successful, the <tt>Modules</tt> should check itself and return a non-empty string if checking fails. # Properties #* checks are usually fast # Return Value #* empty string “” if successful, else a message #Sample Code for Optimization: <pre> public String check(){ s = ""; // 1. check connected modules for (Object o: evaluables) { String so=((IModule)o).check(); if (so.length > 0){ s += “checking connected module with ID “ + (IModule o).getID() + “ failed with message: \\n” + so; } } if (s.length > 0){ return “checking connected modules failed: \\n” + s; // 2. check this module, return String if not successful if (opt.verbose > 3) s+= "Option verbose must be between 0 and 3, but is set to " + opt.verbose + "\\n"; // … return s; } </pre> == Method <tt>String init(long index)</tt> == Currently the <tt>index</tt> is not used! # Functionality #* initialize <tt>Modules</tt> such that executing optimizations or learning processes is possible. #* Initialization requires several steps: #*# check if the argument (index) has changed compared to the time of the last check (see also example below). If the argument has not changed, the system has not changed and a new initialization is not necessary. Thus, return the message of the previous check and do no further checking. #*# If the <tt>Modules</tt> is connected to other Modules, it should first #*#* call the <tt>init()</tt> of the connected <tt>Modules</tt> and #*#* return a message, if any connected <tt>Modules</tt> fails to initialize #*# If the initialization of the connected <tt>Modules</tt> is successful, it should then get the properties of the connected <tt>Modules</tt> #*#* return a message, if any connected <tt>Modules</tt> fails to return properties. #*# Initialize itself and return a string if initialization fails. # Objectives #* initialization should never lead to exceptions. #* It must not call <tt>check()</tt>! # Properties #* the <tt>init()</tt> method is the only method of <tt>IModule</tt> that may require CPU time (e.g. for loading a large data source). Thus this method should not be called too often. # Advanced Features #* the<tt>Modules</tt> should check if initialization is necessary. Typically initialization is necessary when #** the <tt>Options</tt> of the<tt>Modules</tt> are changed #** the connections of the<tt>Modules</tt> changed #** the properties of the connected <i>Modules</i> changed #* if nothing changed, it should not initialize in order to save computer resources # Return Value #* empty string “” if successful, else a message # Sample Code for Optimization: <pre> public string init(long init_id){ s = ""; if (this.init_id == init_id){ return [the message of the last initialization]; this.init_id = init_id; for (Object o: evaluables) { String so=((IModule)o).init(init_id); if (so.length > 0){ s += “initializing connected module with ID “ + (IModule o).getID() + “ failed with message: \\n” + so; } } if (s.length > 0){ return “initializing connected modules failed: \\n” + s; // initialize this module, return String if not successful // … return s; } </pre> '''Summary''' Properties of a <tt>Module</tt> should only change when the Method <tt>init()</tt> is called. This guarantees that <tt>Modules</tt> do not change while they are checked or other <tt>Modules</tt> are running! == Method <tt>int getID()</tt> == # Functionality #* gets the ID for this <tt>Module</tt>. # Objectives #* the ID is important for debugging, e.g. <tt>Modules</tt> can identify to which other <tt>Modules</tt> they are connected. == Method <tt>void setID(int id)</tt> == # Functionality #* sets the ID for this <tt>Module</tt>. # Objectives #* IDs should be set at the time of instantiation and should not be modified. #* the ID is important for debugging, e.g. <tt>Modules</tt> can identify to which other <tt>Modules</tt> they are connected. == Method <tt>String getInfo()</tt> == # Functionality #* Returns a String in HTML or plain text, describing the module #* A<tt>Modules</tt> such as an optimization algorithm should return the problem properties when it this<tt>Modules</tt> is called. # Objectives #* get information about<tt>Modules</tt> properties for checking or debugging user settings 0 35 126 69 2013-09-12T20:22:50Z Admin 1 wikitext text/x-wiki OpenDINO consists of 3 parts # the GUI # the Core # many Modules == The GUI == The graphical user interface (GUI) allows setting complex systems by clicking and dragging. It allows to add or remove <code>Modules</code> and to define their interactions by so called <code>Connections</code>. == The Core == The <code>Core</code> handles all file operation as well as provides the basic functionality such that <code>Modules</code> can be implemented. == The Modules == The <code>Modules</code> contain all functionality such as optimization algorithms, protocol functions, visualization of results, and optimization problems. All <code>Modules</code> must implement the interface [ <code>IModule</code>] 154 126 2014-03-19T22:06:50Z Admin 1 wikitext text/x-wiki OpenDino consists of 3 parts # the GUI # the Core # many Modules == The GUI == The graphical user interface (GUI) allows setting complex systems by clicking and dragging. It allows to add or remove <code>Modules</code> and to define their interactions by so called <code>Connections</code>. == The Core == The <code>Core</code> handles all file operation as well as provides the basic functionality such that <code>Modules</code> can be implemented. == The Modules == The <code>Modules</code> contain all functionality such as optimization algorithms, protocol functions, visualization of results, and optimization problems. All <code>Modules</code> must implement the interface [ <code>IModule</code>] 0 34 127 65 2013-09-12T20:23:10Z Admin 1 wikitext text/x-wiki == Introduction == Given some data, machine learning infers relations among them. Well known representatives of machine learning are Artificial Neural Networks and Support Vector Machines. The goal in OpenDINO is to use these techniques to build models either to speed up optimization runs or to post-process the result both [[Documentation/DoE | DoE]] and [[Documentation/Optimization | optimization]]. 155 127 2014-03-19T22:07:16Z Admin 1 wikitext text/x-wiki == Introduction == Given some data, machine learning infers relations among them. Well known representatives of machine learning are Artificial Neural Networks and Support Vector Machines. The goal in OpenDino is to use these techniques to build models either to speed up optimization runs or to post-process the result both [[Documentation/DoE | DoE]] and [[Documentation/Optimization | optimization]]. 6 43 132 2014-03-18T20:36:35Z Dirk 2 wikitext text/x-wiki 133 132 2014-03-18T21:24:50Z Dirk 2 uploaded a new version of &quot;[[File:MainGUI.png]]&quot; wikitext text/x-wiki 6 44 134 2014-03-18T21:25:35Z Dirk 2 wikitext text/x-wiki 6 45 135 2014-03-18T21:26:01Z Dirk 2 wikitext text/x-wiki 136 135 2014-03-18T21:28:18Z Dirk 2 uploaded a new version of &quot;[[File:Optimization.png]]&quot; wikitext text/x-wiki 6 46 137 2014-03-18T21:28:55Z Dirk 2 wikitext text/x-wiki 6 48 146 2014-03-19T22:01:36Z Admin 1 wikitext text/x-wiki 0 26 160 33 2015-10-21T18:55:36Z Dirk 2 /* Terminology */ wikitext text/x-wiki == Notation == As a math parser is currently not used, we write the math equations as formated text: * Scalars are written as small italic letters, e.g. ''f'' * Vectors are written as small bold letters, e.g. '''x'''. * Matrices are written in capital bold letters, e.g. '''C'''. == Symbols == :{| cellpadding="5" width="95%" |- | ''f'', '''f''' | objective function(s) |- | ''x'', '''x''' | design variable(s) |- | ''g'', '''g''' | constraint(s) |- |} == Terminology == :{| cellpadding="10" width="90%" |- | ''solution'' | The term solution is used in optimization. One solution ('''x''','''f''','''g''','''a''') consists of a vector of design variables '''x''', the evaluated objective(s) '''f'''('''x'''), constraint(s) '''g'''('''x''')''', and optionally of additional values '''a'''. |- | ''design variables'' | The vector of design variables '''x''' may consist of real numbers (continuous variables), integers (discrete variables) or both (mixed variables). |- |} 161 160 2015-10-21T19:09:20Z Dirk 2 /* Terminology */ wikitext text/x-wiki == Notation == As a math parser is currently not used, we write the math equations as formated text: * Scalars are written as small italic letters, e.g. ''f'' * Vectors are written as small bold letters, e.g. '''x'''. * Matrices are written in capital bold letters, e.g. '''C'''. == Symbols == :{| cellpadding="5" width="95%" |- | ''f'', '''f''' | objective function(s) |- | ''x'', '''x''' | design variable(s) |- | ''g'', '''g''' | constraint(s) |- |} == Terminology == :{| cellpadding="5" cellspacing="0" width="95%" border="1" |- | ''solution'' | The term solution is used in optimization. One solution ('''x''','''f''','''g''','''a''') consists of a vector of design variables '''x''', the evaluated objective(s) '''f'''('''x'''), constraint(s) '''g'''('''x'''), and optionally of additional values '''a'''. |- | ''design variables'' | The vector of design variables '''x''' may consist of real numbers (continuous variables), integers (discrete variables) or both (mixed variables). |- | ''objectives'' | An optimization problem must have at least one objective or one constraint. OpenDino requires that the objective(s) '''f''' is/are to be minimized. A maximization of a function ''k'' can be converted into minimization by using ''f'' = -''k''. |- | ''constraints'' | Constraints '''c''' are criteria that have to be fulfilled. OpenDino defines a constraint ''c'' as * fulfilled, if ''c'' =< 0 * violated, if ''c'' > 0. The most simple constraint handling in optimization is to add a penalty to the objective function if the constraint is vialoted, resulting in ''f'' + max(0, ''c''). |-|} 162 161 2015-10-21T19:12:16Z Dirk 2 /* Terminology */ wikitext text/x-wiki == Notation == As a math parser is currently not used, we write the math equations as formated text: * Scalars are written as small italic letters, e.g. ''f'' * Vectors are written as small bold letters, e.g. '''x'''. * Matrices are written in capital bold letters, e.g. '''C'''. == Symbols == :{| cellpadding="5" width="95%" |- | ''f'', '''f''' | objective function(s) |- | ''x'', '''x''' | design variable(s) |- | ''g'', '''g''' | constraint(s) |- |} == Terminology == :{| cellpadding="5" cellspacing="0" width="95%" border="1" |- | ''additionals'' | Additionals '''a''' are additional values in a '''solution''' that are for information only and do not influence the optimization. For example, if an optimization problem returns an objective function that is a sum of several values, these values could be added to the solution as additional values '''a'''. |- | ''constraints'' | Constraints '''c''' are criteria that have to be fulfilled. OpenDino defines a constraint ''c'' as * fulfilled, if ''c'' =< 0 * violated, if ''c'' > 0. The most simple constraint handling in optimization is to add a penalty to the objective function if the constraint is vialoted, resulting in ''f'' + max(0, ''c''). |- | ''design variables'' | The vector of design variables '''x''' may consist of real numbers (continuous variables), integers (discrete variables) or both (mixed variables). |- | ''objectives'' | An optimization problem must have at least one objective or one constraint. OpenDino requires that the objective(s) '''f''' is/are to be minimized. A maximization of a function ''k'' can be converted into minimization by using ''f'' = -''k''. |- | ''solution'' | The term solution is used in optimization. One solution ('''x''','''f''','''g''','''a''') consists of a vector of design variables '''x''', the evaluated objective(s) '''f'''('''x'''), constraint(s) '''g'''('''x'''), and optionally of additional values '''a'''. |-|} 163 162 2015-10-21T19:12:53Z Dirk 2 /* Terminology */ wikitext text/x-wiki == Notation == As a math parser is currently not used, we write the math equations as formated text: * Scalars are written as small italic letters, e.g. ''f'' * Vectors are written as small bold letters, e.g. '''x'''. * Matrices are written in capital bold letters, e.g. '''C'''. == Symbols == :{| cellpadding="5" width="95%" |- | ''f'', '''f''' | objective function(s) |- | ''x'', '''x''' | design variable(s) |- | ''g'', '''g''' | constraint(s) |- |} == Terminology == :{| cellpadding="5" cellspacing="0" width="95%" border="1" |- | ''additionals'' | Additionals '''a''' are additional values in a '''solution''' that are for information only and do not influence the optimization. For example, if an optimization problem returns an objective function that is a sum of several values, these values could be added to the solution as additional values '''a'''. |- | ''constraints'' | Constraints '''g''' are criteria that have to be fulfilled. OpenDino defines a constraint ''g'' as * fulfilled, if ''g'' =< 0 * violated, if ''g'' > 0. The most simple constraint handling in optimization is to add a penalty to the objective function if the constraint is vialoted, resulting in ''f'' + max(0, ''g''). |- | ''design variables'' | The vector of design variables '''x''' may consist of real numbers (continuous variables), integers (discrete variables) or both (mixed variables). |- | ''objectives'' | An optimization problem must have at least one objective or one constraint. OpenDino requires that the objective(s) '''f''' is/are to be minimized. A maximization of a function ''k'' can be converted into minimization by using ''f'' = -''k''. |- | ''solution'' | The term solution is used in optimization. One solution ('''x''','''f''','''g''','''a''') consists of a vector of design variables '''x''', the evaluated objective(s) '''f'''('''x'''), constraint(s) '''g'''('''x'''), and optionally of additional values '''a'''. |-|} 164 163 2015-10-21T19:13:56Z Dirk 2 /* Symbols */ wikitext text/x-wiki == Notation == As a math parser is currently not used, we write the math equations as formated text: * Scalars are written as small italic letters, e.g. ''f'' * Vectors are written as small bold letters, e.g. '''x'''. * Matrices are written in capital bold letters, e.g. '''C'''. == Symbols == :{| cellpadding="5" width="95%" |- | ''a'', '''a''' | additionals, i.e. additional value(s) | ''f'', '''f''' | objective function(s) |- | ''x'', '''x''' | design variable(s) |- | ''g'', '''g''' | constraint(s) |- |} == Terminology == :{| cellpadding="5" cellspacing="0" width="95%" border="1" |- | ''additionals'' | Additionals '''a''' are additional values in a '''solution''' that are for information only and do not influence the optimization. For example, if an optimization problem returns an objective function that is a sum of several values, these values could be added to the solution as additional values '''a'''. |- | ''constraints'' | Constraints '''g''' are criteria that have to be fulfilled. OpenDino defines a constraint ''g'' as * fulfilled, if ''g'' =< 0 * violated, if ''g'' > 0. The most simple constraint handling in optimization is to add a penalty to the objective function if the constraint is vialoted, resulting in ''f'' + max(0, ''g''). |- | ''design variables'' | The vector of design variables '''x''' may consist of real numbers (continuous variables), integers (discrete variables) or both (mixed variables). |- | ''objectives'' | An optimization problem must have at least one objective or one constraint. OpenDino requires that the objective(s) '''f''' is/are to be minimized. A maximization of a function ''k'' can be converted into minimization by using ''f'' = -''k''. |- | ''solution'' | The term solution is used in optimization. One solution ('''x''','''f''','''g''','''a''') consists of a vector of design variables '''x''', the evaluated objective(s) '''f'''('''x'''), constraint(s) '''g'''('''x'''), and optionally of additional values '''a'''. |-|} 165 164 2015-10-21T19:14:10Z Dirk 2 /* Symbols */ wikitext text/x-wiki == Notation == As a math parser is currently not used, we write the math equations as formated text: * Scalars are written as small italic letters, e.g. ''f'' * Vectors are written as small bold letters, e.g. '''x'''. * Matrices are written in capital bold letters, e.g. '''C'''. == Symbols == :{| cellpadding="5" width="95%" |- | ''a'', '''a''' | additionals, i.e. additional value(s) |- | ''f'', '''f''' | objective function(s) |- | ''x'', '''x''' | design variable(s) |- | ''g'', '''g''' | constraint(s) |- |} == Terminology == :{| cellpadding="5" cellspacing="0" width="95%" border="1" |- | ''additionals'' | Additionals '''a''' are additional values in a '''solution''' that are for information only and do not influence the optimization. For example, if an optimization problem returns an objective function that is a sum of several values, these values could be added to the solution as additional values '''a'''. |- | ''constraints'' | Constraints '''g''' are criteria that have to be fulfilled. OpenDino defines a constraint ''g'' as * fulfilled, if ''g'' =< 0 * violated, if ''g'' > 0. The most simple constraint handling in optimization is to add a penalty to the objective function if the constraint is vialoted, resulting in ''f'' + max(0, ''g''). |- | ''design variables'' | The vector of design variables '''x''' may consist of real numbers (continuous variables), integers (discrete variables) or both (mixed variables). |- | ''objectives'' | An optimization problem must have at least one objective or one constraint. OpenDino requires that the objective(s) '''f''' is/are to be minimized. A maximization of a function ''k'' can be converted into minimization by using ''f'' = -''k''. |- | ''solution'' | The term solution is used in optimization. One solution ('''x''','''f''','''g''','''a''') consists of a vector of design variables '''x''', the evaluated objective(s) '''f'''('''x'''), constraint(s) '''g'''('''x'''), and optionally of additional values '''a'''. |-|} 166 165 2015-10-21T19:14:29Z Dirk 2 /* Symbols */ wikitext text/x-wiki == Notation == As a math parser is currently not used, we write the math equations as formated text: * Scalars are written as small italic letters, e.g. ''f'' * Vectors are written as small bold letters, e.g. '''x'''. * Matrices are written in capital bold letters, e.g. '''C'''. == Symbols == :{| cellpadding="5" width="95%" |- | ''a'', '''a''' | additionals, i.e. additional value(s) |- | ''f'', '''f''' | objective function(s) |- | ''g'', '''g''' | constraint(s) |- | ''x'', '''x''' | design variable(s) |- |} == Terminology == :{| cellpadding="5" cellspacing="0" width="95%" border="1" |- | ''additionals'' | Additionals '''a''' are additional values in a '''solution''' that are for information only and do not influence the optimization. For example, if an optimization problem returns an objective function that is a sum of several values, these values could be added to the solution as additional values '''a'''. |- | ''constraints'' | Constraints '''g''' are criteria that have to be fulfilled. OpenDino defines a constraint ''g'' as * fulfilled, if ''g'' =< 0 * violated, if ''g'' > 0. The most simple constraint handling in optimization is to add a penalty to the objective function if the constraint is vialoted, resulting in ''f'' + max(0, ''g''). |- | ''design variables'' | The vector of design variables '''x''' may consist of real numbers (continuous variables), integers (discrete variables) or both (mixed variables). |- | ''objectives'' | An optimization problem must have at least one objective or one constraint. OpenDino requires that the objective(s) '''f''' is/are to be minimized. A maximization of a function ''k'' can be converted into minimization by using ''f'' = -''k''. |- | ''solution'' | The term solution is used in optimization. One solution ('''x''','''f''','''g''','''a''') consists of a vector of design variables '''x''', the evaluated objective(s) '''f'''('''x'''), constraint(s) '''g'''('''x'''), and optionally of additional values '''a'''. |-|} 182 166 2015-10-25T17:38:30Z Dirk 2 /* Terminology */ wikitext text/x-wiki == Notation == As a math parser is currently not used, we write the math equations as formated text: * Scalars are written as small italic letters, e.g. ''f'' * Vectors are written as small bold letters, e.g. '''x'''. * Matrices are written in capital bold letters, e.g. '''C'''. == Symbols == :{| cellpadding="5" width="95%" |- | ''a'', '''a''' | additionals, i.e. additional value(s) |- | ''f'', '''f''' | objective function(s) |- | ''g'', '''g''' | constraint(s) |- | ''x'', '''x''' | design variable(s) |- |} == Terminology == :{| cellpadding="5" cellspacing="0" width="95%" border="1" |- | ''additionals'' | Additionals '''a''' are additional values in a '''solution''' that are for information only and do not influence the optimization. For example, if an optimization problem returns an objective function that is a sum of several values, these values could be added to the solution as additional values '''a'''. |- | ''constraints'' | Constraints '''g''' are criteria that have to be fulfilled. OpenDino defines a constraint ''g'' as * fulfilled, if ''g'' =< 0 * violated, if ''g'' > 0. The most simple constraint handling in optimization is to add a penalty to the objective function if the constraint is vialoted, resulting in ''f'' + max(0, ''g''). |- | ''design variables'' | The vector of design variables '''x''' may consist of real numbers (continuous variables), integers (discrete variables) or both (mixed variables). |- | ''objectives'' | An optimization problem must have at least one objective or one constraint. OpenDino requires that the objective(s) '''f''' is/are to be minimized. A maximization of a function ''k'' can be converted into minimization by using ''f'' = -''k''. |- | ''solution'' <div id="solution"></div> | The term solution is used in optimization. One solution ('''x''','''f''','''g''','''a''') consists of a vector of design variables '''x''', the evaluated objective(s) '''f'''('''x'''), constraint(s) '''g'''('''x'''), and optionally of additional values '''a'''. |-|} 183 182 2015-10-25T17:39:39Z Dirk 2 /* Terminology */ wikitext text/x-wiki == Notation == As a math parser is currently not used, we write the math equations as formated text: * Scalars are written as small italic letters, e.g. ''f'' * Vectors are written as small bold letters, e.g. '''x'''. * Matrices are written in capital bold letters, e.g. '''C'''. == Symbols == :{| cellpadding="5" width="95%" |- | ''a'', '''a''' | additionals, i.e. additional value(s) |- | ''f'', '''f''' | objective function(s) |- | ''g'', '''g''' | constraint(s) |- | ''x'', '''x''' | design variable(s) |- |} == Terminology == :{| cellpadding="5" cellspacing="0" width="95%" border="1" |- | ''additionals'' <div id="additionals"></div> | Additionals '''a''' are additional values in a '''solution''' that are for information only and do not influence the optimization. For example, if an optimization problem returns an objective function that is a sum of several values, these values could be added to the solution as additional values '''a'''. |- | ''constraints'' <div id="constraints"></div> | Constraints '''g''' are criteria that have to be fulfilled. OpenDino defines a constraint ''g'' as * fulfilled, if ''g'' =< 0 * violated, if ''g'' > 0. The most simple constraint handling in optimization is to add a penalty to the objective function if the constraint is vialoted, resulting in ''f'' + max(0, ''g''). |- | ''design variables'' <div id="design_variables"></div> | The vector of design variables '''x''' may consist of real numbers (continuous variables), integers (discrete variables) or both (mixed variables). |- | ''objectives'' <div id="objectives"></div> | An optimization problem must have at least one objective or one constraint. OpenDino requires that the objective(s) '''f''' is/are to be minimized. A maximization of a function ''k'' can be converted into minimization by using ''f'' = -''k''. |- | ''solution'' <div id="solution"></div> | The term solution is used in optimization. One solution ('''x''','''f''','''g''','''a''') consists of a vector of design variables '''x''', the evaluated objective(s) '''f'''('''x'''), constraint(s) '''g'''('''x'''), and optionally of additional values '''a'''. |-|} 0 2 167 138 2015-10-25T10:52:25Z Dirk 2 /* Welcome to OpenDino */ wikitext text/x-wiki = Welcome to '''OpenDino''' = '''OpenDino ''' is an open source platform for optimization, design of experiment and learning. The platform is a successor of the terminated [http://www.openopal.org OpenOpal] project. '''OpenDino''' is written in Java. It provides a graphical user interface (GUI) and a platform which simplifies integration of new algorithms as "Modules". Implemented Modules Evolutionary Algorithms: * CMA-ES * (1+1)-ES * Differential Evolution Deterministic optimization algorithm: * SIMPLEX Learning: * a simple Artificial Neural Net Optimization problems: * test functions * interface for executing other programs (solvers) * parallel execution of problems * distributed execution of problems via socket connection between computers Others: * data storage * data analyser and viewer Contact: * [mailto:help@opendino.org help@opendino.org] 0 13 168 43 2015-10-25T10:54:56Z Dirk 2 /* Summary */ wikitext text/x-wiki ==Summary== This optimization module is an implementation of the Evolution Strategy with Covariance Matrix Adaptation (CMA-ES). It uses the source code of Nikolaus Hansen ( https://www.lri.fr/~hansen/cmaes_inmatlab.html#java ). Among the tree evolutionary operators (Recombination, Mutation, Selection), the mutation is considered the most important. Mutation is performed by sampling a Covariance Matrix. The parameters of the matrix (variances and correlation coefficients) are adapted by tracking the path of successful mutations. ==Properties== ===General=== {| class="wikitable" style="text-align:left" border="2" cellpadding="5" cellspacing="5" |- ! Algorithm | stochastic - generates new solutions by sampling a probability function, however deterministic adaptation of the covariance matrix. |- ! Design Variables | Written for continuous variables. No discrete or mixed variables are possible. |- ! Objectives | single-objective for minimization. |- ! Constraint handling | no |- ! Boundary handling | yes |- ! Initialization | Requires at least one of the following: initial solution, initial search region, or bounds. |- |} ===Connections=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Starting at this module | Module requires exactly one connection of type <code>optimization</code>. |- ! Ending at this module | - |- |} ===Actions=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Name !! Description |- ! '''Run''' | starts the optimization. |- |} ===Options=== The options are currently only described in the references (see below). ==Module Description== === Initialization === The algorithm distinguishes several cases, depending on the problem properties (<code>initial solution, initial search region, bounds</code>). === Optimization === The algorithm contains stochastic processes and operates with a population. Parallelization on the basis of the population size is implemented. ==Usage== ... todo ==Source Code== ToDo:Link to SVN ==References== Detailed information is given at http://www.lri.fr/~hansen/ . 170 168 2015-10-25T10:58:11Z Dirk 2 /* General */ wikitext text/x-wiki ==Summary== This optimization module is an implementation of the Evolution Strategy with Covariance Matrix Adaptation (CMA-ES). It uses the source code of Nikolaus Hansen ( https://www.lri.fr/~hansen/cmaes_inmatlab.html#java ). Among the tree evolutionary operators (Recombination, Mutation, Selection), the mutation is considered the most important. Mutation is performed by sampling a Covariance Matrix. The parameters of the matrix (variances and correlation coefficients) are adapted by tracking the path of successful mutations. ==Properties== ===General=== {| class="wikitable" style="text-align:left" border="2" cellpadding="5" cellspacing="5" |- ! Algorithm | stochastic - generates new solutions by sampling a probability function, however deterministic adaptation of the covariance matrix. |- ! Design Variables | Written for continuous variables. No discrete or mixed variables are possible. |- ! Objectives | single-objective for minimization. |- ! Constraint handling | no, use e.g. the Module [[Documentation/Modules/ConstraintHandler | <code>ConstraintHandler</code>. |- ! Boundary handling | yes, the module [[Documentation/Modules/BoundHandler | <code>BoundHandler</code> is integrated in this module. |- ! Initialization | Requires at least one of the following: initial solution, initial search region, or bounds. |- |} ===Connections=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Starting at this module | Module requires exactly one connection of type <code>optimization</code>. |- ! Ending at this module | - |- |} ===Actions=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Name !! Description |- ! '''Run''' | starts the optimization. |- |} ===Options=== The options are currently only described in the references (see below). ==Module Description== === Initialization === The algorithm distinguishes several cases, depending on the problem properties (<code>initial solution, initial search region, bounds</code>). === Optimization === The algorithm contains stochastic processes and operates with a population. Parallelization on the basis of the population size is implemented. ==Usage== ... todo ==Source Code== ToDo:Link to SVN ==References== Detailed information is given at http://www.lri.fr/~hansen/ . 171 170 2015-10-25T10:59:54Z Dirk 2 /* Source Code */ wikitext text/x-wiki ==Summary== This optimization module is an implementation of the Evolution Strategy with Covariance Matrix Adaptation (CMA-ES). It uses the source code of Nikolaus Hansen ( https://www.lri.fr/~hansen/cmaes_inmatlab.html#java ). Among the tree evolutionary operators (Recombination, Mutation, Selection), the mutation is considered the most important. Mutation is performed by sampling a Covariance Matrix. The parameters of the matrix (variances and correlation coefficients) are adapted by tracking the path of successful mutations. ==Properties== ===General=== {| class="wikitable" style="text-align:left" border="2" cellpadding="5" cellspacing="5" |- ! Algorithm | stochastic - generates new solutions by sampling a probability function, however deterministic adaptation of the covariance matrix. |- ! Design Variables | Written for continuous variables. No discrete or mixed variables are possible. |- ! Objectives | single-objective for minimization. |- ! Constraint handling | no, use e.g. the Module [[Documentation/Modules/ConstraintHandler | <code>ConstraintHandler</code>. |- ! Boundary handling | yes, the module [[Documentation/Modules/BoundHandler | <code>BoundHandler</code> is integrated in this module. |- ! Initialization | Requires at least one of the following: initial solution, initial search region, or bounds. |- |} ===Connections=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Starting at this module | Module requires exactly one connection of type <code>optimization</code>. |- ! Ending at this module | - |- |} ===Actions=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Name !! Description |- ! '''Run''' | starts the optimization. |- |} ===Options=== The options are currently only described in the references (see below). ==Module Description== === Initialization === The algorithm distinguishes several cases, depending on the problem properties (<code>initial solution, initial search region, bounds</code>). === Optimization === The algorithm contains stochastic processes and operates with a population. Parallelization on the basis of the population size is implemented. ==Usage== ... todo ==Source Code== http://sourceforge.net/p/opendino/code/HEAD/tree/trunk/src/fr/inria/optimization/cmaes/ http://sourceforge.net/p/opendino/code/HEAD/tree/trunk/src/org/opendino/modules/optAlg/OptAlgCMA.java ==References== Detailed information is given at http://www.lri.fr/~hansen/ . 172 171 2015-10-25T11:00:06Z Dirk 2 /* Source Code */ wikitext text/x-wiki ==Summary== This optimization module is an implementation of the Evolution Strategy with Covariance Matrix Adaptation (CMA-ES). It uses the source code of Nikolaus Hansen ( https://www.lri.fr/~hansen/cmaes_inmatlab.html#java ). Among the tree evolutionary operators (Recombination, Mutation, Selection), the mutation is considered the most important. Mutation is performed by sampling a Covariance Matrix. The parameters of the matrix (variances and correlation coefficients) are adapted by tracking the path of successful mutations. ==Properties== ===General=== {| class="wikitable" style="text-align:left" border="2" cellpadding="5" cellspacing="5" |- ! Algorithm | stochastic - generates new solutions by sampling a probability function, however deterministic adaptation of the covariance matrix. |- ! Design Variables | Written for continuous variables. No discrete or mixed variables are possible. |- ! Objectives | single-objective for minimization. |- ! Constraint handling | no, use e.g. the Module [[Documentation/Modules/ConstraintHandler | <code>ConstraintHandler</code>. |- ! Boundary handling | yes, the module [[Documentation/Modules/BoundHandler | <code>BoundHandler</code> is integrated in this module. |- ! Initialization | Requires at least one of the following: initial solution, initial search region, or bounds. |- |} ===Connections=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Starting at this module | Module requires exactly one connection of type <code>optimization</code>. |- ! Ending at this module | - |- |} ===Actions=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Name !! Description |- ! '''Run''' | starts the optimization. |- |} ===Options=== The options are currently only described in the references (see below). ==Module Description== === Initialization === The algorithm distinguishes several cases, depending on the problem properties (<code>initial solution, initial search region, bounds</code>). === Optimization === The algorithm contains stochastic processes and operates with a population. Parallelization on the basis of the population size is implemented. ==Usage== ... todo ==Source Code== http://sourceforge.net/p/opendino/code/HEAD/tree/trunk/src/fr/inria/optimization/cmaes/ http://sourceforge.net/p/opendino/code/HEAD/tree/trunk/src/org/opendino/modules/optAlg/OptAlgCMA.java ==References== Detailed information is given at http://www.lri.fr/~hansen/ . 0 11 169 151 2015-10-25T10:56:40Z Dirk 2 /* Optimization in General */ wikitext text/x-wiki '''Modules''' contain all the functionality for optimizing and learning. One '''Modules''' may contain an optimization algorithm, an artificial neural network, or a problem to optimize. Here is a list of documented modules in OpenDino. Further modules may exist, but may not yet be documented. == Single Objective Optimization Algorithms == === Indirect, Deterministic Algorithms === Not implemented, yet. === Direct, Deterministic Algorithms === * [[Documentation/Modules/OptAlgSIMPLEX | <code>OptAlgSIMPLEX</code>: Nelder-Mead Simplex Algorithm]] === Indirect, Stochastic Algorithms === * Evolutionary Algorithms ** [[Documentation/Modules/OptAlgOpO|<code>OptAlgOpO</code>: 1+1 Evolution Strategy with 1/5 Success Rule]] ** [[Documentation/Modules/OptAlgCMA|<code>OptAlgCMA</code>: A Multi-member Evolution Strategy with Covariance Matrix Adaptation]] == Single and Multi-Objective Optimization Algorithms == === Indirect, Stochastic Algorithms === * Evolutionary Algorithms ** [[Documentation/Modules/OptAlgMoCMA | <code>OptAlgMoCMA</code>: Elitist Evolution Strategy with Covariance Matrix Adaptation]] * Particle Methods ** [[Documentation/Modules/OptAlgMOPSO | <code>OptAlgMOPSO</code>: Particle Swarm Optimization Algorithm]] == Design of Experiments == * [[Documentation/Modules/DoePlanner | <code>DoePlanner</code>: A Module Containing Different DoE plans]] * [[Documentation/Modules/RandomSampling | <code>RandomSampling</code>: Uniform Random Sampling]] == Optimization in General == * [[Documentation/Modules/BoundHandler | <code>BoundHandler</code> For Optimization Algorithms without Bound Handling]] * [[Documentation/Modules/ConstraintHandler | <code>BoundHandler</code> For Optimization Algorithms without Constraint Handling]] == Optimization Problems == * [[Documentation/Modules/ProblemSimple | <code>ProblemSimple</code> A Simple Test Problem]] * [[Documentation/Modules/ContinuousTestProblems | <code>ContinuousTestProblems </code>: A Set of Single Objective Test Problem]] * [[Documentation/Modules/ContinuousMOTestProblems | <code>ContinuousMOTestProblems </code>: A Set of Multi-Objective Test Problem]] == Machine Learning == * [[Documentation/Modules/NeuralNetwork | <code>NeuralNetwork</code>: Artificial Neural Network]] == Miscellaneous Modules == * [[Documentation/Modules/SurrogateManager | <code>SurrogateManager</code>: A Framework for Surrogate Managing]] 173 169 2015-10-25T11:06:17Z Dirk 2 /* Single Objective Optimization Algorithms */ wikitext text/x-wiki '''Modules''' contain all the functionality for optimizing and learning. One '''Modules''' may contain an optimization algorithm, an artificial neural network, or a problem to optimize. Here is a list of documented modules in OpenDino. Further modules may exist, but may not yet be documented. == Single Objective Optimization Algorithms == === Indirect, Deterministic Algorithms === Indirect algorithms use gradient or higher order derivative information in the optimization. Not implemented, yet. === Direct, Deterministic Algorithms === These algorithms neither use gradient information nor stochastic processes. * [[Documentation/Modules/OptAlgSIMPLEX | <code>OptAlgSIMPLEX</code>: Nelder-Mead Simplex Algorithm]] === Indirect, Stochastic Algorithms === These algorithms do not use gradient information but require stochastic processes (i.e. random numbers) in their search. * Evolutionary Algorithms ** [[Documentation/Modules/OptAlgOpO|<code>OptAlgOpO</code>: 1+1 Evolution Strategy with 1/5 Success Rule]] ** [[Documentation/Modules/OptAlgCMA|<code>OptAlgCMA</code>: A Multi-member Evolution Strategy with Covariance Matrix Adaptation]] == Single and Multi-Objective Optimization Algorithms == === Indirect, Stochastic Algorithms === * Evolutionary Algorithms ** [[Documentation/Modules/OptAlgMoCMA | <code>OptAlgMoCMA</code>: Elitist Evolution Strategy with Covariance Matrix Adaptation]] * Particle Methods ** [[Documentation/Modules/OptAlgMOPSO | <code>OptAlgMOPSO</code>: Particle Swarm Optimization Algorithm]] == Design of Experiments == * [[Documentation/Modules/DoePlanner | <code>DoePlanner</code>: A Module Containing Different DoE plans]] * [[Documentation/Modules/RandomSampling | <code>RandomSampling</code>: Uniform Random Sampling]] == Optimization in General == * [[Documentation/Modules/BoundHandler | <code>BoundHandler</code> For Optimization Algorithms without Bound Handling]] * [[Documentation/Modules/ConstraintHandler | <code>BoundHandler</code> For Optimization Algorithms without Constraint Handling]] == Optimization Problems == * [[Documentation/Modules/ProblemSimple | <code>ProblemSimple</code> A Simple Test Problem]] * [[Documentation/Modules/ContinuousTestProblems | <code>ContinuousTestProblems </code>: A Set of Single Objective Test Problem]] * [[Documentation/Modules/ContinuousMOTestProblems | <code>ContinuousMOTestProblems </code>: A Set of Multi-Objective Test Problem]] == Machine Learning == * [[Documentation/Modules/NeuralNetwork | <code>NeuralNetwork</code>: Artificial Neural Network]] == Miscellaneous Modules == * [[Documentation/Modules/SurrogateManager | <code>SurrogateManager</code>: A Framework for Surrogate Managing]] 174 173 2015-10-25T11:07:30Z Dirk 2 /* Indirect, Stochastic Algorithms */ wikitext text/x-wiki '''Modules''' contain all the functionality for optimizing and learning. One '''Modules''' may contain an optimization algorithm, an artificial neural network, or a problem to optimize. Here is a list of documented modules in OpenDino. Further modules may exist, but may not yet be documented. == Single Objective Optimization Algorithms == === Indirect, Deterministic Algorithms === Indirect algorithms use gradient or higher order derivative information in the optimization. Not implemented, yet. === Direct, Deterministic Algorithms === These algorithms neither use gradient information nor stochastic processes. * [[Documentation/Modules/OptAlgSIMPLEX | <code>OptAlgSIMPLEX</code>: Nelder-Mead Simplex Algorithm]] === Indirect, Stochastic Algorithms === These algorithms do not use gradient information but require stochastic processes (i.e. random numbers) in their search. * Evolutionary Algorithms ** [[Documentation/Modules/OptAlgOpO|<code>OptAlgOpO</code>: 1+1 Evolution Strategy with 1/5 Success Rule: the (1+1)-ES]] ** [[Documentation/Modules/OptAlgCMA|<code>OptAlgCMA</code>: A Multi-member Evolution Strategy with Covariance Matrix Adaptation: the CMA-ES]] == Single and Multi-Objective Optimization Algorithms == === Indirect, Stochastic Algorithms === * Evolutionary Algorithms ** [[Documentation/Modules/OptAlgMoCMA | <code>OptAlgMoCMA</code>: Elitist Evolution Strategy with Covariance Matrix Adaptation]] * Particle Methods ** [[Documentation/Modules/OptAlgMOPSO | <code>OptAlgMOPSO</code>: Particle Swarm Optimization Algorithm]] == Design of Experiments == * [[Documentation/Modules/DoePlanner | <code>DoePlanner</code>: A Module Containing Different DoE plans]] * [[Documentation/Modules/RandomSampling | <code>RandomSampling</code>: Uniform Random Sampling]] == Optimization in General == * [[Documentation/Modules/BoundHandler | <code>BoundHandler</code> For Optimization Algorithms without Bound Handling]] * [[Documentation/Modules/ConstraintHandler | <code>BoundHandler</code> For Optimization Algorithms without Constraint Handling]] == Optimization Problems == * [[Documentation/Modules/ProblemSimple | <code>ProblemSimple</code> A Simple Test Problem]] * [[Documentation/Modules/ContinuousTestProblems | <code>ContinuousTestProblems </code>: A Set of Single Objective Test Problem]] * [[Documentation/Modules/ContinuousMOTestProblems | <code>ContinuousMOTestProblems </code>: A Set of Multi-Objective Test Problem]] == Machine Learning == * [[Documentation/Modules/NeuralNetwork | <code>NeuralNetwork</code>: Artificial Neural Network]] == Miscellaneous Modules == * [[Documentation/Modules/SurrogateManager | <code>SurrogateManager</code>: A Framework for Surrogate Managing]] 175 174 2015-10-25T11:08:17Z Dirk 2 /* Single and Multi-Objective Optimization Algorithms */ wikitext text/x-wiki '''Modules''' contain all the functionality for optimizing and learning. One '''Modules''' may contain an optimization algorithm, an artificial neural network, or a problem to optimize. Here is a list of documented modules in OpenDino. Further modules may exist, but may not yet be documented. == Single Objective Optimization Algorithms == === Indirect, Deterministic Algorithms === Indirect algorithms use gradient or higher order derivative information in the optimization. Not implemented, yet. === Direct, Deterministic Algorithms === These algorithms neither use gradient information nor stochastic processes. * [[Documentation/Modules/OptAlgSIMPLEX | <code>OptAlgSIMPLEX</code>: Nelder-Mead Simplex Algorithm]] === Indirect, Stochastic Algorithms === These algorithms do not use gradient information but require stochastic processes (i.e. random numbers) in their search. * Evolutionary Algorithms ** [[Documentation/Modules/OptAlgOpO|<code>OptAlgOpO</code>: 1+1 Evolution Strategy with 1/5 Success Rule: the (1+1)-ES]] ** [[Documentation/Modules/OptAlgCMA|<code>OptAlgCMA</code>: A Multi-member Evolution Strategy with Covariance Matrix Adaptation: the CMA-ES]] == Single and Multi-Objective Optimization Algorithms == === Indirect, Stochastic Algorithms === * Evolutionary Algorithms ** [[Documentation/Modules/OptAlgMoCMA | <code>OptAlgMoCMA</code>]]: Elitist Evolution Strategy with Covariance Matrix Adaptation * Particle Methods ** [[Documentation/Modules/OptAlgMOPSO | <code>OptAlgMOPSO</code>]]: Particle Swarm Optimization Algorithm == Design of Experiments == * [[Documentation/Modules/DoePlanner | <code>DoePlanner</code>: A Module Containing Different DoE plans]] * [[Documentation/Modules/RandomSampling | <code>RandomSampling</code>: Uniform Random Sampling]] == Optimization in General == * [[Documentation/Modules/BoundHandler | <code>BoundHandler</code> For Optimization Algorithms without Bound Handling]] * [[Documentation/Modules/ConstraintHandler | <code>BoundHandler</code> For Optimization Algorithms without Constraint Handling]] == Optimization Problems == * [[Documentation/Modules/ProblemSimple | <code>ProblemSimple</code> A Simple Test Problem]] * [[Documentation/Modules/ContinuousTestProblems | <code>ContinuousTestProblems </code>: A Set of Single Objective Test Problem]] * [[Documentation/Modules/ContinuousMOTestProblems | <code>ContinuousMOTestProblems </code>: A Set of Multi-Objective Test Problem]] == Machine Learning == * [[Documentation/Modules/NeuralNetwork | <code>NeuralNetwork</code>: Artificial Neural Network]] == Miscellaneous Modules == * [[Documentation/Modules/SurrogateManager | <code>SurrogateManager</code>: A Framework for Surrogate Managing]] 176 175 2015-10-25T11:08:48Z Dirk 2 /* Direct, Deterministic Algorithms */ wikitext text/x-wiki '''Modules''' contain all the functionality for optimizing and learning. One '''Modules''' may contain an optimization algorithm, an artificial neural network, or a problem to optimize. Here is a list of documented modules in OpenDino. Further modules may exist, but may not yet be documented. == Single Objective Optimization Algorithms == === Indirect, Deterministic Algorithms === Indirect algorithms use gradient or higher order derivative information in the optimization. Not implemented, yet. === Direct, Deterministic Algorithms === These algorithms neither use gradient information nor stochastic processes. * [[Documentation/Modules/OptAlgSIMPLEX | <code>OptAlgSIMPLEX</code>]]: Nelder-Mead Simplex Algorithm === Indirect, Stochastic Algorithms === These algorithms do not use gradient information but require stochastic processes (i.e. random numbers) in their search. * Evolutionary Algorithms ** [[Documentation/Modules/OptAlgOpO|<code>OptAlgOpO</code>: 1+1 Evolution Strategy with 1/5 Success Rule: the (1+1)-ES]] ** [[Documentation/Modules/OptAlgCMA|<code>OptAlgCMA</code>: A Multi-member Evolution Strategy with Covariance Matrix Adaptation: the CMA-ES]] == Single and Multi-Objective Optimization Algorithms == === Indirect, Stochastic Algorithms === * Evolutionary Algorithms ** [[Documentation/Modules/OptAlgMoCMA | <code>OptAlgMoCMA</code>]]: Elitist Evolution Strategy with Covariance Matrix Adaptation * Particle Methods ** [[Documentation/Modules/OptAlgMOPSO | <code>OptAlgMOPSO</code>]]: Particle Swarm Optimization Algorithm == Design of Experiments == * [[Documentation/Modules/DoePlanner | <code>DoePlanner</code>: A Module Containing Different DoE plans]] * [[Documentation/Modules/RandomSampling | <code>RandomSampling</code>: Uniform Random Sampling]] == Optimization in General == * [[Documentation/Modules/BoundHandler | <code>BoundHandler</code> For Optimization Algorithms without Bound Handling]] * [[Documentation/Modules/ConstraintHandler | <code>BoundHandler</code> For Optimization Algorithms without Constraint Handling]] == Optimization Problems == * [[Documentation/Modules/ProblemSimple | <code>ProblemSimple</code> A Simple Test Problem]] * [[Documentation/Modules/ContinuousTestProblems | <code>ContinuousTestProblems </code>: A Set of Single Objective Test Problem]] * [[Documentation/Modules/ContinuousMOTestProblems | <code>ContinuousMOTestProblems </code>: A Set of Multi-Objective Test Problem]] == Machine Learning == * [[Documentation/Modules/NeuralNetwork | <code>NeuralNetwork</code>: Artificial Neural Network]] == Miscellaneous Modules == * [[Documentation/Modules/SurrogateManager | <code>SurrogateManager</code>: A Framework for Surrogate Managing]] 177 176 2015-10-25T11:09:03Z Dirk 2 /* Indirect, Stochastic Algorithms */ wikitext text/x-wiki '''Modules''' contain all the functionality for optimizing and learning. One '''Modules''' may contain an optimization algorithm, an artificial neural network, or a problem to optimize. Here is a list of documented modules in OpenDino. Further modules may exist, but may not yet be documented. == Single Objective Optimization Algorithms == === Indirect, Deterministic Algorithms === Indirect algorithms use gradient or higher order derivative information in the optimization. Not implemented, yet. === Direct, Deterministic Algorithms === These algorithms neither use gradient information nor stochastic processes. * [[Documentation/Modules/OptAlgSIMPLEX | <code>OptAlgSIMPLEX</code>]]: Nelder-Mead Simplex Algorithm === Indirect, Stochastic Algorithms === These algorithms do not use gradient information but require stochastic processes (i.e. random numbers) in their search. * Evolutionary Algorithms ** [[Documentation/Modules/OptAlgOpO|<code>OptAlgOpO</code>]]: 1+1 Evolution Strategy with 1/5 Success Rule: the (1+1)-ES ** [[Documentation/Modules/OptAlgCMA|<code>OptAlgCMA</code>]]: A Multi-member Evolution Strategy with Covariance Matrix Adaptation: the CMA-ES == Single and Multi-Objective Optimization Algorithms == === Indirect, Stochastic Algorithms === * Evolutionary Algorithms ** [[Documentation/Modules/OptAlgMoCMA | <code>OptAlgMoCMA</code>]]: Elitist Evolution Strategy with Covariance Matrix Adaptation * Particle Methods ** [[Documentation/Modules/OptAlgMOPSO | <code>OptAlgMOPSO</code>]]: Particle Swarm Optimization Algorithm == Design of Experiments == * [[Documentation/Modules/DoePlanner | <code>DoePlanner</code>: A Module Containing Different DoE plans]] * [[Documentation/Modules/RandomSampling | <code>RandomSampling</code>: Uniform Random Sampling]] == Optimization in General == * [[Documentation/Modules/BoundHandler | <code>BoundHandler</code> For Optimization Algorithms without Bound Handling]] * [[Documentation/Modules/ConstraintHandler | <code>BoundHandler</code> For Optimization Algorithms without Constraint Handling]] == Optimization Problems == * [[Documentation/Modules/ProblemSimple | <code>ProblemSimple</code> A Simple Test Problem]] * [[Documentation/Modules/ContinuousTestProblems | <code>ContinuousTestProblems </code>: A Set of Single Objective Test Problem]] * [[Documentation/Modules/ContinuousMOTestProblems | <code>ContinuousMOTestProblems </code>: A Set of Multi-Objective Test Problem]] == Machine Learning == * [[Documentation/Modules/NeuralNetwork | <code>NeuralNetwork</code>: Artificial Neural Network]] == Miscellaneous Modules == * [[Documentation/Modules/SurrogateManager | <code>SurrogateManager</code>: A Framework for Surrogate Managing]] 178 177 2015-10-25T11:10:43Z Dirk 2 wikitext text/x-wiki '''Modules''' contain all the functionality for optimizing and learning. One '''Modules''' may contain an optimization algorithm, an artificial neural network, or a problem to optimize. Here is a list of documented modules in OpenDino. Further modules may exist, but may not yet be documented. == Single Objective Optimization Algorithms == === Indirect, Deterministic Algorithms === Indirect algorithms use gradient or higher order derivative information in the optimization. Not implemented, yet. === Direct, Deterministic Algorithms === These algorithms neither use gradient information nor stochastic processes. * [[Documentation/Modules/OptAlgSIMPLEX | <code>OptAlgSIMPLEX</code>]]: Nelder-Mead Simplex Algorithm === Indirect, Stochastic Algorithms === These algorithms do not use gradient information but require stochastic processes (i.e. random numbers) in their search. * Evolutionary Algorithms ** [[Documentation/Modules/OptAlgOpO|<code>OptAlgOpO</code>]]: 1+1 Evolution Strategy with 1/5 Success Rule: the (1+1)-ES ** [[Documentation/Modules/OptAlgCMA|<code>OptAlgCMA</code>]]: A Multi-member Evolution Strategy with Covariance Matrix Adaptation: the CMA-ES == Single and Multi-Objective Optimization Algorithms == === Indirect, Stochastic Algorithms === * Evolutionary Algorithms ** [[Documentation/Modules/OptAlgMoCMA | <code>OptAlgMoCMA</code>]]: Elitist Evolution Strategy with Covariance Matrix Adaptation * Particle Methods ** [[Documentation/Modules/OptAlgMOPSO | <code>OptAlgMOPSO</code>]]: Particle Swarm Optimization Algorithm == Design of Experiments == * [[Documentation/Modules/DoePlanner | <code>DoePlanner</code>]]: A Module Containing Different DoE plans * [[Documentation/Modules/RandomSampling | <code>RandomSampling</code>]]: Uniform Random Sampling (Monte Carlo) == Optimization in General == * [[Documentation/Modules/BoundHandler | <code>BoundHandler</code>]]: For Optimization Algorithms without Bound Handling * [[Documentation/Modules/ConstraintHandler | <code>ConstraintHandler </code>]]: For Optimization Algorithms without Constraint Handling == Optimization Problems == * [[Documentation/Modules/ProblemSimple | <code>ProblemSimple</code>]] A Simple Test Problem * [[Documentation/Modules/ContinuousTestProblems | <code>ContinuousTestProblems </code>]]: A Set of Single Objective Test Problem * [[Documentation/Modules/ContinuousMOTestProblems | <code>ContinuousMOTestProblems </code>]]: A Set of Multi-Objective Test Problem == Machine Learning == * [[Documentation/Modules/NeuralNetwork | <code>NeuralNetwork</code>]]: Artificial Neural Network == Miscellaneous Modules == * [[Documentation/Modules/SurrogateManager | <code>SurrogateManager</code>]]: A Framework for Surrogate Managing 185 178 2015-10-25T17:46:41Z Dirk 2 /* Optimization Problems */ wikitext text/x-wiki '''Modules''' contain all the functionality for optimizing and learning. One '''Modules''' may contain an optimization algorithm, an artificial neural network, or a problem to optimize. Here is a list of documented modules in OpenDino. Further modules may exist, but may not yet be documented. == Single Objective Optimization Algorithms == === Indirect, Deterministic Algorithms === Indirect algorithms use gradient or higher order derivative information in the optimization. Not implemented, yet. === Direct, Deterministic Algorithms === These algorithms neither use gradient information nor stochastic processes. * [[Documentation/Modules/OptAlgSIMPLEX | <code>OptAlgSIMPLEX</code>]]: Nelder-Mead Simplex Algorithm === Indirect, Stochastic Algorithms === These algorithms do not use gradient information but require stochastic processes (i.e. random numbers) in their search. * Evolutionary Algorithms ** [[Documentation/Modules/OptAlgOpO|<code>OptAlgOpO</code>]]: 1+1 Evolution Strategy with 1/5 Success Rule: the (1+1)-ES ** [[Documentation/Modules/OptAlgCMA|<code>OptAlgCMA</code>]]: A Multi-member Evolution Strategy with Covariance Matrix Adaptation: the CMA-ES == Single and Multi-Objective Optimization Algorithms == === Indirect, Stochastic Algorithms === * Evolutionary Algorithms ** [[Documentation/Modules/OptAlgMoCMA | <code>OptAlgMoCMA</code>]]: Elitist Evolution Strategy with Covariance Matrix Adaptation * Particle Methods ** [[Documentation/Modules/OptAlgMOPSO | <code>OptAlgMOPSO</code>]]: Particle Swarm Optimization Algorithm == Design of Experiments == * [[Documentation/Modules/DoePlanner | <code>DoePlanner</code>]]: A Module Containing Different DoE plans * [[Documentation/Modules/RandomSampling | <code>RandomSampling</code>]]: Uniform Random Sampling (Monte Carlo) == Optimization in General == * [[Documentation/Modules/BoundHandler | <code>BoundHandler</code>]]: For Optimization Algorithms without Bound Handling * [[Documentation/Modules/ConstraintHandler | <code>ConstraintHandler </code>]]: For Optimization Algorithms without Constraint Handling == Optimization Problems == * [[Documentation/Modules/ProblemSimple | <code>ProblemSimple</code>]] A Simple Test Problem * [[Documentation/Modules/ContinuousTestProblems | <code>ContinuousTestProblems </code>]]: A Set of Single Objective Test Problem * [[Documentation/Modules/ContinuousMOTestProblems | <code>ContinuousMOTestProblems </code>]]: A Set of Multi-Objective Test Problem * [[Documentation/Modules/ProblemTruss | <code>ProblemTruss </code>]]: The goal is to opzimize the thickness of 10 trusses. The weight of the truess, maximum stress, and displacement can each be set either as objective or constraint. == Machine Learning == * [[Documentation/Modules/NeuralNetwork | <code>NeuralNetwork</code>]]: Artificial Neural Network == Miscellaneous Modules == * [[Documentation/Modules/SurrogateManager | <code>SurrogateManager</code>]]: A Framework for Surrogate Managing 0 41 179 102 2015-10-25T11:11:30Z Dirk 2 /* Properties */ wikitext text/x-wiki ==Summary== Some optimizations require bounds on the design variables '''xxx'''. E.g. for the diameter of any mechanical support must be above a certain minimum value. As not all optimization algorithms include bound handling, the module <code>BoundHandler</code> was created. ==Properties== ===General=== {| class="wikitable" style="text-align:left" border="2" cellpadding="5" cellspacing="5" |- ! Algorithm | deterministic |- ! Design Variables | continuous variables, discrete or mixed variables are possible. |- ! Objectives | any number |- ! Constraints | any number |- ! Boundaries | Design variables values outside the boundaries are corrected |- ! Initial Search Region | not affected |- ! Typical X | not affected |- ! Initialization | not required |- |} ===Connections=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Starting at his module | One connection of type <code>optimization</code> |- ! Ending at this module | One connection of type <code>optimization</code> |- |} ===Actions=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Name !! Description |- ! - | - |- |} ===Options=== The options are currently described as "pop-up help". ==Module Description== Any optimization algorithm proposes a new solution '''x'''. Some of the values of '''x''' might be outside the lower bounds x_l and upper bounds x_u, specified in the "Problem" module. These variables are corrected to values within the bounds by two different methods: 1. set to bounds If one of the variables x is below or above the bounds, it is set to the bound value, i.e. if x < x_l, then x = x_l else if x > x_u, then x = x_u 2. reflect If one of the variables x is below or above the bounds, it is reflected from the bound. The reflection is done such that if x goes to infinity, x is equal to the lower bound and if x goes to minus infinity, it is set to the upper bound. if x < x_l, then x = x_u + (x_l- x_u) / (x - x_u) * (x_l- x_u); else if x > x_u, then x = x_l + (x_u- x_l) / (x - x_l) * (x_u- x_l) ==Usage== - ==Source Code== ToDo:Link to SVN ==References== - 180 179 2015-10-25T11:25:56Z Dirk 2 /* Module Description */ wikitext text/x-wiki ==Summary== Some optimizations require bounds on the design variables '''xxx'''. E.g. for the diameter of any mechanical support must be above a certain minimum value. As not all optimization algorithms include bound handling, the module <code>BoundHandler</code> was created. ==Properties== ===General=== {| class="wikitable" style="text-align:left" border="2" cellpadding="5" cellspacing="5" |- ! Algorithm | deterministic |- ! Design Variables | continuous variables, discrete or mixed variables are possible. |- ! Objectives | any number |- ! Constraints | any number |- ! Boundaries | Design variables values outside the boundaries are corrected |- ! Initial Search Region | not affected |- ! Typical X | not affected |- ! Initialization | not required |- |} ===Connections=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Starting at his module | One connection of type <code>optimization</code> |- ! Ending at this module | One connection of type <code>optimization</code> |- |} ===Actions=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Name !! Description |- ! - | - |- |} ===Options=== The options are currently described as "pop-up help". ==Module Description== The optimization algorithm proposes one or several new solutions '''x'''. Some values of '''x''' might be outside the lower bounds x_l and upper bounds x_u, specified in the "Problem" module. These variables are corrected to values within the bounds by thress different methods: 0. no bound handling This option turns off the bound handling. 1. set to bounds If one of the variables x is below or above the bounds, it is set to the bound value, i.e. if x < x_l, then x = x_l else if x > x_u, then x = x_u 2. reflect If one of the variables x is below or above the bounds, it is reflected from the bound. The reflection is done such that if x goes to infinity, x is equal to the lower bound and if x goes to minus infinity, it is set to the upper bound. if x < x_l, then x = x_u + (x_l- x_u)^2 / (x - x_u) else if x > x_u, then x = x_l + (x_u- x_l)^2 / (x - x_l) ==Usage== - ==Source Code== ToDo:Link to SVN ==References== - 181 180 2015-10-25T11:26:46Z Dirk 2 /* Properties */ wikitext text/x-wiki ==Summary== Some optimizations require bounds on the design variables '''xxx'''. E.g. for the diameter of any mechanical support must be above a certain minimum value. As not all optimization algorithms include bound handling, the module <code>BoundHandler</code> was created. ==Properties== ===General=== {| class="wikitable" style="text-align:left" border="2" cellpadding="5" cellspacing="5" |- ! Algorithm | deterministic (as no gradient handling is implemented) |- ! Design Variables | continuous variables, discrete or mixed variables are possible. |- ! Objectives | any number |- ! Constraints | any number |- ! Boundaries | Design variables values outside the boundaries are corrected |- ! Initial Search Region | not affected |- ! Typical X | not affected |- ! Initialization | not required |- |} ===Connections=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Starting at his module | One connection of type <code>optimization</code> |- ! Ending at this module | One connection of type <code>optimization</code> |- |} ===Actions=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Name !! Description |- ! - | - |- |} ===Options=== The options are currently described as "pop-up help". ==Module Description== The optimization algorithm proposes one or several new solutions '''x'''. Some values of '''x''' might be outside the lower bounds x_l and upper bounds x_u, specified in the "Problem" module. These variables are corrected to values within the bounds by thress different methods: 0. no bound handling This option turns off the bound handling. 1. set to bounds If one of the variables x is below or above the bounds, it is set to the bound value, i.e. if x < x_l, then x = x_l else if x > x_u, then x = x_u 2. reflect If one of the variables x is below or above the bounds, it is reflected from the bound. The reflection is done such that if x goes to infinity, x is equal to the lower bound and if x goes to minus infinity, it is set to the upper bound. if x < x_l, then x = x_u + (x_l- x_u)^2 / (x - x_u) else if x > x_u, then x = x_l + (x_u- x_l)^2 / (x - x_l) ==Usage== - ==Source Code== ToDo:Link to SVN ==References== - 0 49 184 2015-10-25T17:42:24Z Dirk 2 Created page with "==Summary== Some optimization problems require objective functions as well as [[Documentation/Notation#constraints | constraints]]. require bounds on the design variables '''x..." wikitext text/x-wiki ==Summary== Some optimization problems require objective functions as well as [[Documentation/Notation#constraints | constraints]]. require bounds on the design variables '''xxx'''. E.g. for the diameter of any mechanical support must be above a certain minimum value. As not all optimization algorithms include bound handling, the module <code>BoundHandler</code> was created. ==Properties== ===General=== {| class="wikitable" style="text-align:left" border="2" cellpadding="5" cellspacing="5" |- ! Algorithm | deterministic (as no gradient handling is implemented) |- ! Design Variables | continuous variables, discrete or mixed variables are possible. |- ! Objectives | any number |- ! Constraints | any number |- ! Boundaries | Design variables values outside the boundaries are corrected |- ! Initial Search Region | not affected |- ! Typical X | not affected |- ! Initialization | not required |- |} ===Connections=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Starting at his module | One connection of type <code>optimization</code> |- ! Ending at this module | One connection of type <code>optimization</code> |- |} ===Actions=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Name !! Description |- ! - | - |- |} ===Options=== The options are currently described as "pop-up help". ==Module Description== The optimization algorithm proposes one or several new solutions '''x'''. Some values of '''x''' might be outside the lower bounds x_l and upper bounds x_u, specified in the "Problem" module. These variables are corrected to values within the bounds by thress different methods: 0. no bound handling This option turns off the bound handling. 1. set to bounds If one of the variables x is below or above the bounds, it is set to the bound value, i.e. if x < x_l, then x = x_l else if x > x_u, then x = x_u 2. reflect If one of the variables x is below or above the bounds, it is reflected from the bound. The reflection is done such that if x goes to infinity, x is equal to the lower bound and if x goes to minus infinity, it is set to the upper bound. if x < x_l, then x = x_u + (x_l- x_u)^2 / (x - x_u) else if x > x_u, then x = x_l + (x_u- x_l)^2 / (x - x_l) ==Usage== - ==Source Code== ToDo:Link to SVN ==References== - 186 184 2015-10-25T17:48:40Z Dirk 2 /* Summary */ wikitext text/x-wiki ==Summary== Some optimization problems define [[Documentation/Notation#objectives | objectives]] as well as [[Documentation/Notation#constraints | constraints]]. For example, one can set for the optimization problem [[Documentation/Modules/ProblemTruss | <code>ProblemTruss </code>]] the weight of the truss to be minimized, while a constraint is set on the maximum stress and displacement of the truss. This module aggregates objectives and constraints into a single output. ==Properties== ===General=== {| class="wikitable" style="text-align:left" border="2" cellpadding="5" cellspacing="5" |- ! Algorithm | deterministic (as no gradient handling is implemented) |- ! Design Variables | continuous variables, discrete or mixed variables are possible. |- ! Objectives | any number |- ! Constraints | any number |- ! Boundaries | Design variables values outside the boundaries are corrected |- ! Initial Search Region | not affected |- ! Typical X | not affected |- ! Initialization | not required |- |} ===Connections=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Starting at his module | One connection of type <code>optimization</code> |- ! Ending at this module | One connection of type <code>optimization</code> |- |} ===Actions=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Name !! Description |- ! - | - |- |} ===Options=== The options are currently described as "pop-up help". ==Module Description== The optimization algorithm proposes one or several new solutions '''x'''. Some values of '''x''' might be outside the lower bounds x_l and upper bounds x_u, specified in the "Problem" module. These variables are corrected to values within the bounds by thress different methods: 0. no bound handling This option turns off the bound handling. 1. set to bounds If one of the variables x is below or above the bounds, it is set to the bound value, i.e. if x < x_l, then x = x_l else if x > x_u, then x = x_u 2. reflect If one of the variables x is below or above the bounds, it is reflected from the bound. The reflection is done such that if x goes to infinity, x is equal to the lower bound and if x goes to minus infinity, it is set to the upper bound. if x < x_l, then x = x_u + (x_l- x_u)^2 / (x - x_u) else if x > x_u, then x = x_l + (x_u- x_l)^2 / (x - x_l) ==Usage== - ==Source Code== ToDo:Link to SVN ==References== - 187 186 2015-10-25T17:53:06Z Dirk 2 /* Properties */ wikitext text/x-wiki ==Summary== Some optimization problems define [[Documentation/Notation#objectives | objectives]] as well as [[Documentation/Notation#constraints | constraints]]. For example, one can set for the optimization problem [[Documentation/Modules/ProblemTruss | <code>ProblemTruss </code>]] the weight of the truss to be minimized, while a constraint is set on the maximum stress and displacement of the truss. This module aggregates objectives and constraints into a single output. ==Properties== ===General=== {| class="wikitable" style="text-align:left" border="2" cellpadding="5" cellspacing="5" |- ! Algorithm | deterministic (as no gradient handling is implemented) |- ! Design Variables | continuous variables, discrete or mixed variables are possible. |- ! Objectives | any number |- ! Constraints | any number |- ! Boundaries | not affected |- ! Initial Search Region | not affected |- ! Typical X | not affected |- ! Initialization | not required |- |} ===Connections=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Starting at his module | One connection of type <code>optimization</code> |- ! Ending at this module | One connection of type <code>optimization</code> |- |} ===Actions=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Name !! Description |- ! - | - |- |} ===Options=== The options are currently described as "pop-up help". ==Module Description== The optimization algorithm proposes one or several new solutions '''x'''. Some values of '''x''' might be outside the lower bounds x_l and upper bounds x_u, specified in the "Problem" module. These variables are corrected to values within the bounds by thress different methods: 0. no bound handling This option turns off the bound handling. 1. set to bounds If one of the variables x is below or above the bounds, it is set to the bound value, i.e. if x < x_l, then x = x_l else if x > x_u, then x = x_u 2. reflect If one of the variables x is below or above the bounds, it is reflected from the bound. The reflection is done such that if x goes to infinity, x is equal to the lower bound and if x goes to minus infinity, it is set to the upper bound. if x < x_l, then x = x_u + (x_l- x_u)^2 / (x - x_u) else if x > x_u, then x = x_l + (x_u- x_l)^2 / (x - x_l) ==Usage== - ==Source Code== ToDo:Link to SVN ==References== - 188 187 2015-10-25T17:54:19Z Dirk 2 /* Module Description */ wikitext text/x-wiki ==Summary== Some optimization problems define [[Documentation/Notation#objectives | objectives]] as well as [[Documentation/Notation#constraints | constraints]]. For example, one can set for the optimization problem [[Documentation/Modules/ProblemTruss | <code>ProblemTruss </code>]] the weight of the truss to be minimized, while a constraint is set on the maximum stress and displacement of the truss. This module aggregates objectives and constraints into a single output. ==Properties== ===General=== {| class="wikitable" style="text-align:left" border="2" cellpadding="5" cellspacing="5" |- ! Algorithm | deterministic (as no gradient handling is implemented) |- ! Design Variables | continuous variables, discrete or mixed variables are possible. |- ! Objectives | any number |- ! Constraints | any number |- ! Boundaries | not affected |- ! Initial Search Region | not affected |- ! Typical X | not affected |- ! Initialization | not required |- |} ===Connections=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Starting at his module | One connection of type <code>optimization</code> |- ! Ending at this module | One connection of type <code>optimization</code> |- |} ===Actions=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Name !! Description |- ! - | - |- |} ===Options=== The options are currently described as "pop-up help". ==Module Description== The result of an evaluation of a solution may contain objective values '''f''' and constraint values '''g''': 0. no bound handling This option turns off the bound handling. 1. set to bounds If one of the variables x is below or above the bounds, it is set to the bound value, i.e. if x < x_l, then x = x_l else if x > x_u, then x = x_u 2. reflect If one of the variables x is below or above the bounds, it is reflected from the bound. The reflection is done such that if x goes to infinity, x is equal to the lower bound and if x goes to minus infinity, it is set to the upper bound. if x < x_l, then x = x_u + (x_l- x_u)^2 / (x - x_u) else if x > x_u, then x = x_l + (x_u- x_l)^2 / (x - x_l) ==Usage== - ==Source Code== ToDo:Link to SVN ==References== - 189 188 2015-10-25T18:11:51Z Dirk 2 /* Module Description */ wikitext text/x-wiki ==Summary== Some optimization problems define [[Documentation/Notation#objectives | objectives]] as well as [[Documentation/Notation#constraints | constraints]]. For example, one can set for the optimization problem [[Documentation/Modules/ProblemTruss | <code>ProblemTruss </code>]] the weight of the truss to be minimized, while a constraint is set on the maximum stress and displacement of the truss. This module aggregates objectives and constraints into a single output. ==Properties== ===General=== {| class="wikitable" style="text-align:left" border="2" cellpadding="5" cellspacing="5" |- ! Algorithm | deterministic (as no gradient handling is implemented) |- ! Design Variables | continuous variables, discrete or mixed variables are possible. |- ! Objectives | any number |- ! Constraints | any number |- ! Boundaries | not affected |- ! Initial Search Region | not affected |- ! Typical X | not affected |- ! Initialization | not required |- |} ===Connections=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Starting at his module | One connection of type <code>optimization</code> |- ! Ending at this module | One connection of type <code>optimization</code> |- |} ===Actions=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Name !! Description |- ! - | - |- |} ===Options=== The options are currently described as "pop-up help". ==Module Description== The result of an evaluation of a solution may contain objective values '''f''' and constraint values '''g''': While bjectives are to be minimized (<code>min('''f''')</code>), constraints are to be fulfilled (<code>'''g''' =< 0</code>). 0. no constraint handling This option turns off the constraint handling. Objective values and constraints are not changed. 1. delete constraints Deletes all constraints. This can be used if the goal is to minimize the objective function(s) only. The objective functions are not changed. 2. Penalty method All objective function values are summed. All violated constraints (i.e. the constraint value is >= 0) are summed and multiplied with a penalty factor <code>p</code>: output = sum_i(f_i) + sum_j(max(g_j,0))*p Increasing the penalty factor <code>p</code> puts more weight on the constraints compared to the objectives. 3. Penalty method This algorithm works only for population based search methods such as CMA-ES. There are 3 steps a. All objective function values are summed: sum_i(f_i) b. All violated constraints (i.e. the constraint value is >= 0) are summed sum_j(max(g_j,0)) c. Ranking of the solutions according to the Stochastic Ranking algorithm of the paper T. P. Runarsson and X. Yao, "Stochastic Ranking for Constrained Evolutionary Optimization", '''IEEE Transactions on Evolutionary Computation''', Vol. 4, No. 3, pp. 284-294, Sep. 2000. ==Usage== - ==Source Code== ToDo:Link to SVN ==References== - 190 189 2015-10-25T18:12:11Z Dirk 2 /* Module Description */ wikitext text/x-wiki ==Summary== Some optimization problems define [[Documentation/Notation#objectives | objectives]] as well as [[Documentation/Notation#constraints | constraints]]. For example, one can set for the optimization problem [[Documentation/Modules/ProblemTruss | <code>ProblemTruss </code>]] the weight of the truss to be minimized, while a constraint is set on the maximum stress and displacement of the truss. This module aggregates objectives and constraints into a single output. ==Properties== ===General=== {| class="wikitable" style="text-align:left" border="2" cellpadding="5" cellspacing="5" |- ! Algorithm | deterministic (as no gradient handling is implemented) |- ! Design Variables | continuous variables, discrete or mixed variables are possible. |- ! Objectives | any number |- ! Constraints | any number |- ! Boundaries | not affected |- ! Initial Search Region | not affected |- ! Typical X | not affected |- ! Initialization | not required |- |} ===Connections=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Starting at his module | One connection of type <code>optimization</code> |- ! Ending at this module | One connection of type <code>optimization</code> |- |} ===Actions=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Name !! Description |- ! - | - |- |} ===Options=== The options are currently described as "pop-up help". ==Module Description== The result of an evaluation of a solution may contain objective values '''f''' and constraint values '''g''': While bjectives are to be minimized (<code>min('''f''')</code>), constraints are to be fulfilled (<code>'''g''' =< 0</code>). 0. no constraint handling This option turns off the constraint handling. Objective values and constraints are not changed. 1. delete constraints Deletes all constraints. This can be used if the goal is to minimize the objective function(s) only. The objective functions are not changed. 2. Penalty method All objective function values are summed. All violated constraints (i.e. the constraint value is >= 0) are summed and multiplied with a penalty factor <code>p</code>: output = sum_i(f_i) + sum_j(max(g_j,0))*p Increasing the penalty factor <code>p</code> puts more weight on the constraints compared to the objectives. 3. Penalty method This algorithm works only for population based search methods such as CMA-ES. There are 3 steps a. All objective function values are summed: sum_i(f_i) b. All violated constraints (i.e. the constraint value is >= 0) are summed: sum_j(max(g_j,0)) c. Ranking of the solutions according to the Stochastic Ranking algorithm of the paper T. P. Runarsson and X. Yao, "Stochastic Ranking for Constrained Evolutionary Optimization", '''IEEE Transactions on Evolutionary Computation''', Vol. 4, No. 3, pp. 284-294, Sep. 2000. ==Usage== - ==Source Code== ToDo:Link to SVN ==References== - 191 190 2015-10-25T18:13:17Z Dirk 2 /* Module Description */ wikitext text/x-wiki ==Summary== Some optimization problems define [[Documentation/Notation#objectives | objectives]] as well as [[Documentation/Notation#constraints | constraints]]. For example, one can set for the optimization problem [[Documentation/Modules/ProblemTruss | <code>ProblemTruss </code>]] the weight of the truss to be minimized, while a constraint is set on the maximum stress and displacement of the truss. This module aggregates objectives and constraints into a single output. ==Properties== ===General=== {| class="wikitable" style="text-align:left" border="2" cellpadding="5" cellspacing="5" |- ! Algorithm | deterministic (as no gradient handling is implemented) |- ! Design Variables | continuous variables, discrete or mixed variables are possible. |- ! Objectives | any number |- ! Constraints | any number |- ! Boundaries | not affected |- ! Initial Search Region | not affected |- ! Typical X | not affected |- ! Initialization | not required |- |} ===Connections=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Starting at his module | One connection of type <code>optimization</code> |- ! Ending at this module | One connection of type <code>optimization</code> |- |} ===Actions=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Name !! Description |- ! - | - |- |} ===Options=== The options are currently described as "pop-up help". ==Module Description== The result of an evaluation of a solution may contain objective values '''f''' and constraint values '''g''': While bjectives are to be minimized (<code>min('''f''')</code>), constraints are to be fulfilled (<code>'''g''' =< 0</code>). 0. no constraint handling This option turns off the constraint handling. Objective values and constraints are not changed. 1. delete constraints Deletes all constraints. This can be used if the goal is to minimize the objective function(s) only. The objective functions are not changed. 2. Penalty method All objective function values are summed. All violated constraints (i.e. the constraint value is >= 0) are summed and multiplied with a penalty factor <code>p</code>: output = sum_i(f_i) + sum_j(max(g_j,0))*p Increasing the penalty factor <code>p</code> puts more weight on the constraints compared to the objectives. 3. Penalty method This algorithm works only for population based search methods such as CMA-ES. There are 3 steps a. All objective function values are summed: sum_i(f_i) b. All violated constraints (i.e. the constraint value is >= 0) are summed: sum_j(max(g_j,0)) c. Ranking of the solutions according to the Stochastic Ranking [[#1|1]] ==Usage== - ==Source Code== ToDo:Link to SVN ==References== - 192 191 2015-10-25T18:14:35Z Dirk 2 /* References */ wikitext text/x-wiki ==Summary== Some optimization problems define [[Documentation/Notation#objectives | objectives]] as well as [[Documentation/Notation#constraints | constraints]]. For example, one can set for the optimization problem [[Documentation/Modules/ProblemTruss | <code>ProblemTruss </code>]] the weight of the truss to be minimized, while a constraint is set on the maximum stress and displacement of the truss. This module aggregates objectives and constraints into a single output. ==Properties== ===General=== {| class="wikitable" style="text-align:left" border="2" cellpadding="5" cellspacing="5" |- ! Algorithm | deterministic (as no gradient handling is implemented) |- ! Design Variables | continuous variables, discrete or mixed variables are possible. |- ! Objectives | any number |- ! Constraints | any number |- ! Boundaries | not affected |- ! Initial Search Region | not affected |- ! Typical X | not affected |- ! Initialization | not required |- |} ===Connections=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Starting at his module | One connection of type <code>optimization</code> |- ! Ending at this module | One connection of type <code>optimization</code> |- |} ===Actions=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Name !! Description |- ! - | - |- |} ===Options=== The options are currently described as "pop-up help". ==Module Description== The result of an evaluation of a solution may contain objective values '''f''' and constraint values '''g''': While bjectives are to be minimized (<code>min('''f''')</code>), constraints are to be fulfilled (<code>'''g''' =< 0</code>). 0. no constraint handling This option turns off the constraint handling. Objective values and constraints are not changed. 1. delete constraints Deletes all constraints. This can be used if the goal is to minimize the objective function(s) only. The objective functions are not changed. 2. Penalty method All objective function values are summed. All violated constraints (i.e. the constraint value is >= 0) are summed and multiplied with a penalty factor <code>p</code>: output = sum_i(f_i) + sum_j(max(g_j,0))*p Increasing the penalty factor <code>p</code> puts more weight on the constraints compared to the objectives. 3. Penalty method This algorithm works only for population based search methods such as CMA-ES. There are 3 steps a. All objective function values are summed: sum_i(f_i) b. All violated constraints (i.e. the constraint value is >= 0) are summed: sum_j(max(g_j,0)) c. Ranking of the solutions according to the Stochastic Ranking [[#1|1]] ==Usage== - ==Source Code== ToDo:Link to SVN ==References== [1]<div id="1">1</div> T. P. Runarsson and X. Yao, "Stochastic Ranking for Constrained Evolutionary Optimization", '''IEEE Transactions on Evolutionary Computation''', Vol. 4, No. 3, pp. 284-294, Sep. 2000. 193 192 2015-10-25T18:14:54Z Dirk 2 /* References */ wikitext text/x-wiki ==Summary== Some optimization problems define [[Documentation/Notation#objectives | objectives]] as well as [[Documentation/Notation#constraints | constraints]]. For example, one can set for the optimization problem [[Documentation/Modules/ProblemTruss | <code>ProblemTruss </code>]] the weight of the truss to be minimized, while a constraint is set on the maximum stress and displacement of the truss. This module aggregates objectives and constraints into a single output. ==Properties== ===General=== {| class="wikitable" style="text-align:left" border="2" cellpadding="5" cellspacing="5" |- ! Algorithm | deterministic (as no gradient handling is implemented) |- ! Design Variables | continuous variables, discrete or mixed variables are possible. |- ! Objectives | any number |- ! Constraints | any number |- ! Boundaries | not affected |- ! Initial Search Region | not affected |- ! Typical X | not affected |- ! Initialization | not required |- |} ===Connections=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Starting at his module | One connection of type <code>optimization</code> |- ! Ending at this module | One connection of type <code>optimization</code> |- |} ===Actions=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Name !! Description |- ! - | - |- |} ===Options=== The options are currently described as "pop-up help". ==Module Description== The result of an evaluation of a solution may contain objective values '''f''' and constraint values '''g''': While bjectives are to be minimized (<code>min('''f''')</code>), constraints are to be fulfilled (<code>'''g''' =< 0</code>). 0. no constraint handling This option turns off the constraint handling. Objective values and constraints are not changed. 1. delete constraints Deletes all constraints. This can be used if the goal is to minimize the objective function(s) only. The objective functions are not changed. 2. Penalty method All objective function values are summed. All violated constraints (i.e. the constraint value is >= 0) are summed and multiplied with a penalty factor <code>p</code>: output = sum_i(f_i) + sum_j(max(g_j,0))*p Increasing the penalty factor <code>p</code> puts more weight on the constraints compared to the objectives. 3. Penalty method This algorithm works only for population based search methods such as CMA-ES. There are 3 steps a. All objective function values are summed: sum_i(f_i) b. All violated constraints (i.e. the constraint value is >= 0) are summed: sum_j(max(g_j,0)) c. Ranking of the solutions according to the Stochastic Ranking [[#1|1]] ==Usage== - ==Source Code== ToDo:Link to SVN ==References== [<div id="1">1</div>] T. P. Runarsson and X. Yao, "Stochastic Ranking for Constrained Evolutionary Optimization", '''IEEE Transactions on Evolutionary Computation''', Vol. 4, No. 3, pp. 284-294, Sep. 2000. 194 193 2015-10-25T18:15:26Z Dirk 2 /* Module Description */ wikitext text/x-wiki ==Summary== Some optimization problems define [[Documentation/Notation#objectives | objectives]] as well as [[Documentation/Notation#constraints | constraints]]. For example, one can set for the optimization problem [[Documentation/Modules/ProblemTruss | <code>ProblemTruss </code>]] the weight of the truss to be minimized, while a constraint is set on the maximum stress and displacement of the truss. This module aggregates objectives and constraints into a single output. ==Properties== ===General=== {| class="wikitable" style="text-align:left" border="2" cellpadding="5" cellspacing="5" |- ! Algorithm | deterministic (as no gradient handling is implemented) |- ! Design Variables | continuous variables, discrete or mixed variables are possible. |- ! Objectives | any number |- ! Constraints | any number |- ! Boundaries | not affected |- ! Initial Search Region | not affected |- ! Typical X | not affected |- ! Initialization | not required |- |} ===Connections=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Starting at his module | One connection of type <code>optimization</code> |- ! Ending at this module | One connection of type <code>optimization</code> |- |} ===Actions=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Name !! Description |- ! - | - |- |} ===Options=== The options are currently described as "pop-up help". ==Module Description== The result of an evaluation of a solution may contain objective values '''f''' and constraint values '''g''': While bjectives are to be minimized (<code>min('''f''')</code>), constraints are to be fulfilled (<code>'''g''' =< 0</code>). 0. no constraint handling This option turns off the constraint handling. Objective values and constraints are not changed. 1. delete constraints Deletes all constraints. This can be used if the goal is to minimize the objective function(s) only. The objective functions are not changed. 2. Penalty method All objective function values are summed. All violated constraints (i.e. the constraint value is >= 0) are summed and multiplied with a penalty factor <code>p</code>: output = sum_i(f_i) + sum_j(max(g_j,0))*p Increasing the penalty factor <code>p</code> puts more weight on the constraints compared to the objectives. 3. Penalty method This algorithm works only for population based search methods such as CMA-ES. There are 3 steps a. All objective function values are summed: sum_i(f_i) b. All violated constraints (i.e. the constraint value is >= 0) are summed: sum_j(max(g_j,0)) c. Ranking of the solutions according to the Stochastic Ranking [[[#1|1]]] ==Usage== - ==Source Code== ToDo:Link to SVN ==References== [<div id="1">1</div>] T. P. Runarsson and X. Yao, "Stochastic Ranking for Constrained Evolutionary Optimization", '''IEEE Transactions on Evolutionary Computation''', Vol. 4, No. 3, pp. 284-294, Sep. 2000. 195 194 2015-10-25T18:15:44Z Dirk 2 /* Module Description */ wikitext text/x-wiki ==Summary== Some optimization problems define [[Documentation/Notation#objectives | objectives]] as well as [[Documentation/Notation#constraints | constraints]]. For example, one can set for the optimization problem [[Documentation/Modules/ProblemTruss | <code>ProblemTruss </code>]] the weight of the truss to be minimized, while a constraint is set on the maximum stress and displacement of the truss. This module aggregates objectives and constraints into a single output. ==Properties== ===General=== {| class="wikitable" style="text-align:left" border="2" cellpadding="5" cellspacing="5" |- ! Algorithm | deterministic (as no gradient handling is implemented) |- ! Design Variables | continuous variables, discrete or mixed variables are possible. |- ! Objectives | any number |- ! Constraints | any number |- ! Boundaries | not affected |- ! Initial Search Region | not affected |- ! Typical X | not affected |- ! Initialization | not required |- |} ===Connections=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Starting at his module | One connection of type <code>optimization</code> |- ! Ending at this module | One connection of type <code>optimization</code> |- |} ===Actions=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Name !! Description |- ! - | - |- |} ===Options=== The options are currently described as "pop-up help". ==Module Description== The result of an evaluation of a solution may contain objective values '''f''' and constraint values '''g''': While bjectives are to be minimized (<code>min('''f''')</code>), constraints are to be fulfilled (<code>'''g''' =< 0</code>). 0. no constraint handling This option turns off the constraint handling. Objective values and constraints are not changed. 1. delete constraints Deletes all constraints. This can be used if the goal is to minimize the objective function(s) only. The objective functions are not changed. 2. Penalty method All objective function values are summed. All violated constraints (i.e. the constraint value is >= 0) are summed and multiplied with a penalty factor <code>p</code>: output = sum_i(f_i) + sum_j(max(g_j,0))*p Increasing the penalty factor <code>p</code> puts more weight on the constraints compared to the objectives. 3. Penalty method This algorithm works only for population based search methods such as CMA-ES. There are 3 steps a. All objective function values are summed: sum_i(f_i) b. All violated constraints (i.e. the constraint value is >= 0) are summed: sum_j(max(g_j,0)) c. Ranking of the solutions according to the Stochastic Ranking ([[#1|1]]) ==Usage== - ==Source Code== ToDo:Link to SVN ==References== [<div id="1">1</div>] T. P. Runarsson and X. Yao, "Stochastic Ranking for Constrained Evolutionary Optimization", '''IEEE Transactions on Evolutionary Computation''', Vol. 4, No. 3, pp. 284-294, Sep. 2000. 196 195 2015-10-25T18:16:00Z Dirk 2 /* References */ wikitext text/x-wiki ==Summary== Some optimization problems define [[Documentation/Notation#objectives | objectives]] as well as [[Documentation/Notation#constraints | constraints]]. For example, one can set for the optimization problem [[Documentation/Modules/ProblemTruss | <code>ProblemTruss </code>]] the weight of the truss to be minimized, while a constraint is set on the maximum stress and displacement of the truss. This module aggregates objectives and constraints into a single output. ==Properties== ===General=== {| class="wikitable" style="text-align:left" border="2" cellpadding="5" cellspacing="5" |- ! Algorithm | deterministic (as no gradient handling is implemented) |- ! Design Variables | continuous variables, discrete or mixed variables are possible. |- ! Objectives | any number |- ! Constraints | any number |- ! Boundaries | not affected |- ! Initial Search Region | not affected |- ! Typical X | not affected |- ! Initialization | not required |- |} ===Connections=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Starting at his module | One connection of type <code>optimization</code> |- ! Ending at this module | One connection of type <code>optimization</code> |- |} ===Actions=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Name !! Description |- ! - | - |- |} ===Options=== The options are currently described as "pop-up help". ==Module Description== The result of an evaluation of a solution may contain objective values '''f''' and constraint values '''g''': While bjectives are to be minimized (<code>min('''f''')</code>), constraints are to be fulfilled (<code>'''g''' =< 0</code>). 0. no constraint handling This option turns off the constraint handling. Objective values and constraints are not changed. 1. delete constraints Deletes all constraints. This can be used if the goal is to minimize the objective function(s) only. The objective functions are not changed. 2. Penalty method All objective function values are summed. All violated constraints (i.e. the constraint value is >= 0) are summed and multiplied with a penalty factor <code>p</code>: output = sum_i(f_i) + sum_j(max(g_j,0))*p Increasing the penalty factor <code>p</code> puts more weight on the constraints compared to the objectives. 3. Penalty method This algorithm works only for population based search methods such as CMA-ES. There are 3 steps a. All objective function values are summed: sum_i(f_i) b. All violated constraints (i.e. the constraint value is >= 0) are summed: sum_j(max(g_j,0)) c. Ranking of the solutions according to the Stochastic Ranking ([[#1|1]]) ==Usage== - ==Source Code== ToDo:Link to SVN ==References== (<div id="1">1</div>) T. P. Runarsson and X. Yao, "Stochastic Ranking for Constrained Evolutionary Optimization", '''IEEE Transactions on Evolutionary Computation''', Vol. 4, No. 3, pp. 284-294, Sep. 2000. 197 196 2015-10-25T18:16:39Z Dirk 2 /* References */ wikitext text/x-wiki ==Summary== Some optimization problems define [[Documentation/Notation#objectives | objectives]] as well as [[Documentation/Notation#constraints | constraints]]. For example, one can set for the optimization problem [[Documentation/Modules/ProblemTruss | <code>ProblemTruss </code>]] the weight of the truss to be minimized, while a constraint is set on the maximum stress and displacement of the truss. This module aggregates objectives and constraints into a single output. ==Properties== ===General=== {| class="wikitable" style="text-align:left" border="2" cellpadding="5" cellspacing="5" |- ! Algorithm | deterministic (as no gradient handling is implemented) |- ! Design Variables | continuous variables, discrete or mixed variables are possible. |- ! Objectives | any number |- ! Constraints | any number |- ! Boundaries | not affected |- ! Initial Search Region | not affected |- ! Typical X | not affected |- ! Initialization | not required |- |} ===Connections=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Starting at his module | One connection of type <code>optimization</code> |- ! Ending at this module | One connection of type <code>optimization</code> |- |} ===Actions=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Name !! Description |- ! - | - |- |} ===Options=== The options are currently described as "pop-up help". ==Module Description== The result of an evaluation of a solution may contain objective values '''f''' and constraint values '''g''': While bjectives are to be minimized (<code>min('''f''')</code>), constraints are to be fulfilled (<code>'''g''' =< 0</code>). 0. no constraint handling This option turns off the constraint handling. Objective values and constraints are not changed. 1. delete constraints Deletes all constraints. This can be used if the goal is to minimize the objective function(s) only. The objective functions are not changed. 2. Penalty method All objective function values are summed. All violated constraints (i.e. the constraint value is >= 0) are summed and multiplied with a penalty factor <code>p</code>: output = sum_i(f_i) + sum_j(max(g_j,0))*p Increasing the penalty factor <code>p</code> puts more weight on the constraints compared to the objectives. 3. Penalty method This algorithm works only for population based search methods such as CMA-ES. There are 3 steps a. All objective function values are summed: sum_i(f_i) b. All violated constraints (i.e. the constraint value is >= 0) are summed: sum_j(max(g_j,0)) c. Ranking of the solutions according to the Stochastic Ranking ([[#1|1]]) ==Usage== - ==Source Code== ToDo:Link to SVN ==References== (<span id="1">1</span>) T. P. Runarsson and X. Yao, "Stochastic Ranking for Constrained Evolutionary Optimization", '''IEEE Transactions on Evolutionary Computation''', Vol. 4, No. 3, pp. 284-294, Sep. 2000. 198 197 2015-10-25T18:18:01Z Dirk 2 /* Usage */ wikitext text/x-wiki ==Summary== Some optimization problems define [[Documentation/Notation#objectives | objectives]] as well as [[Documentation/Notation#constraints | constraints]]. For example, one can set for the optimization problem [[Documentation/Modules/ProblemTruss | <code>ProblemTruss </code>]] the weight of the truss to be minimized, while a constraint is set on the maximum stress and displacement of the truss. This module aggregates objectives and constraints into a single output. ==Properties== ===General=== {| class="wikitable" style="text-align:left" border="2" cellpadding="5" cellspacing="5" |- ! Algorithm | deterministic (as no gradient handling is implemented) |- ! Design Variables | continuous variables, discrete or mixed variables are possible. |- ! Objectives | any number |- ! Constraints | any number |- ! Boundaries | not affected |- ! Initial Search Region | not affected |- ! Typical X | not affected |- ! Initialization | not required |- |} ===Connections=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Starting at his module | One connection of type <code>optimization</code> |- ! Ending at this module | One connection of type <code>optimization</code> |- |} ===Actions=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Name !! Description |- ! - | - |- |} ===Options=== The options are currently described as "pop-up help". ==Module Description== The result of an evaluation of a solution may contain objective values '''f''' and constraint values '''g''': While bjectives are to be minimized (<code>min('''f''')</code>), constraints are to be fulfilled (<code>'''g''' =< 0</code>). 0. no constraint handling This option turns off the constraint handling. Objective values and constraints are not changed. 1. delete constraints Deletes all constraints. This can be used if the goal is to minimize the objective function(s) only. The objective functions are not changed. 2. Penalty method All objective function values are summed. All violated constraints (i.e. the constraint value is >= 0) are summed and multiplied with a penalty factor <code>p</code>: output = sum_i(f_i) + sum_j(max(g_j,0))*p Increasing the penalty factor <code>p</code> puts more weight on the constraints compared to the objectives. 3. Penalty method This algorithm works only for population based search methods such as CMA-ES. There are 3 steps a. All objective function values are summed: sum_i(f_i) b. All violated constraints (i.e. the constraint value is >= 0) are summed: sum_j(max(g_j,0)) c. Ranking of the solutions according to the Stochastic Ranking ([[#1|1]]) ==Usage== https://sourceforge.net/p/opendino/code/HEAD/tree/trunk/src/org/opendino/modules/optim/tools/ConstraintHandler.java ==Source Code== ToDo:Link to SVN ==References== (<span id="1">1</span>) T. P. Runarsson and X. Yao, "Stochastic Ranking for Constrained Evolutionary Optimization", '''IEEE Transactions on Evolutionary Computation''', Vol. 4, No. 3, pp. 284-294, Sep. 2000. 199 198 2015-10-25T18:18:15Z Dirk 2 /* Usage */ wikitext text/x-wiki ==Summary== Some optimization problems define [[Documentation/Notation#objectives | objectives]] as well as [[Documentation/Notation#constraints | constraints]]. For example, one can set for the optimization problem [[Documentation/Modules/ProblemTruss | <code>ProblemTruss </code>]] the weight of the truss to be minimized, while a constraint is set on the maximum stress and displacement of the truss. This module aggregates objectives and constraints into a single output. ==Properties== ===General=== {| class="wikitable" style="text-align:left" border="2" cellpadding="5" cellspacing="5" |- ! Algorithm | deterministic (as no gradient handling is implemented) |- ! Design Variables | continuous variables, discrete or mixed variables are possible. |- ! Objectives | any number |- ! Constraints | any number |- ! Boundaries | not affected |- ! Initial Search Region | not affected |- ! Typical X | not affected |- ! Initialization | not required |- |} ===Connections=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Starting at his module | One connection of type <code>optimization</code> |- ! Ending at this module | One connection of type <code>optimization</code> |- |} ===Actions=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Name !! Description |- ! - | - |- |} ===Options=== The options are currently described as "pop-up help". ==Module Description== The result of an evaluation of a solution may contain objective values '''f''' and constraint values '''g''': While bjectives are to be minimized (<code>min('''f''')</code>), constraints are to be fulfilled (<code>'''g''' =< 0</code>). 0. no constraint handling This option turns off the constraint handling. Objective values and constraints are not changed. 1. delete constraints Deletes all constraints. This can be used if the goal is to minimize the objective function(s) only. The objective functions are not changed. 2. Penalty method All objective function values are summed. All violated constraints (i.e. the constraint value is >= 0) are summed and multiplied with a penalty factor <code>p</code>: output = sum_i(f_i) + sum_j(max(g_j,0))*p Increasing the penalty factor <code>p</code> puts more weight on the constraints compared to the objectives. 3. Penalty method This algorithm works only for population based search methods such as CMA-ES. There are 3 steps a. All objective function values are summed: sum_i(f_i) b. All violated constraints (i.e. the constraint value is >= 0) are summed: sum_j(max(g_j,0)) c. Ranking of the solutions according to the Stochastic Ranking ([[#1|1]]) ==Usage== - ==Source Code== ToDo:Link to SVN ==References== (<span id="1">1</span>) T. P. Runarsson and X. Yao, "Stochastic Ranking for Constrained Evolutionary Optimization", '''IEEE Transactions on Evolutionary Computation''', Vol. 4, No. 3, pp. 284-294, Sep. 2000. 200 199 2015-10-25T18:18:23Z Dirk 2 /* Source Code */ wikitext text/x-wiki ==Summary== Some optimization problems define [[Documentation/Notation#objectives | objectives]] as well as [[Documentation/Notation#constraints | constraints]]. For example, one can set for the optimization problem [[Documentation/Modules/ProblemTruss | <code>ProblemTruss </code>]] the weight of the truss to be minimized, while a constraint is set on the maximum stress and displacement of the truss. This module aggregates objectives and constraints into a single output. ==Properties== ===General=== {| class="wikitable" style="text-align:left" border="2" cellpadding="5" cellspacing="5" |- ! Algorithm | deterministic (as no gradient handling is implemented) |- ! Design Variables | continuous variables, discrete or mixed variables are possible. |- ! Objectives | any number |- ! Constraints | any number |- ! Boundaries | not affected |- ! Initial Search Region | not affected |- ! Typical X | not affected |- ! Initialization | not required |- |} ===Connections=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Starting at his module | One connection of type <code>optimization</code> |- ! Ending at this module | One connection of type <code>optimization</code> |- |} ===Actions=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Name !! Description |- ! - | - |- |} ===Options=== The options are currently described as "pop-up help". ==Module Description== The result of an evaluation of a solution may contain objective values '''f''' and constraint values '''g''': While bjectives are to be minimized (<code>min('''f''')</code>), constraints are to be fulfilled (<code>'''g''' =< 0</code>). 0. no constraint handling This option turns off the constraint handling. Objective values and constraints are not changed. 1. delete constraints Deletes all constraints. This can be used if the goal is to minimize the objective function(s) only. The objective functions are not changed. 2. Penalty method All objective function values are summed. All violated constraints (i.e. the constraint value is >= 0) are summed and multiplied with a penalty factor <code>p</code>: output = sum_i(f_i) + sum_j(max(g_j,0))*p Increasing the penalty factor <code>p</code> puts more weight on the constraints compared to the objectives. 3. Penalty method This algorithm works only for population based search methods such as CMA-ES. There are 3 steps a. All objective function values are summed: sum_i(f_i) b. All violated constraints (i.e. the constraint value is >= 0) are summed: sum_j(max(g_j,0)) c. Ranking of the solutions according to the Stochastic Ranking ([[#1|1]]) ==Usage== - ==Source Code== https://sourceforge.net/p/opendino/code/HEAD/tree/trunk/src/org/opendino/modules/optim/tools/ConstraintHandler.java ==References== (<span id="1">1</span>) T. P. Runarsson and X. Yao, "Stochastic Ranking for Constrained Evolutionary Optimization", '''IEEE Transactions on Evolutionary Computation''', Vol. 4, No. 3, pp. 284-294, Sep. 2000. 201 200 2015-10-25T18:18:36Z Dirk 2 /* References */ wikitext text/x-wiki ==Summary== Some optimization problems define [[Documentation/Notation#objectives | objectives]] as well as [[Documentation/Notation#constraints | constraints]]. For example, one can set for the optimization problem [[Documentation/Modules/ProblemTruss | <code>ProblemTruss </code>]] the weight of the truss to be minimized, while a constraint is set on the maximum stress and displacement of the truss. This module aggregates objectives and constraints into a single output. ==Properties== ===General=== {| class="wikitable" style="text-align:left" border="2" cellpadding="5" cellspacing="5" |- ! Algorithm | deterministic (as no gradient handling is implemented) |- ! Design Variables | continuous variables, discrete or mixed variables are possible. |- ! Objectives | any number |- ! Constraints | any number |- ! Boundaries | not affected |- ! Initial Search Region | not affected |- ! Typical X | not affected |- ! Initialization | not required |- |} ===Connections=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Starting at his module | One connection of type <code>optimization</code> |- ! Ending at this module | One connection of type <code>optimization</code> |- |} ===Actions=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Name !! Description |- ! - | - |- |} ===Options=== The options are currently described as "pop-up help". ==Module Description== The result of an evaluation of a solution may contain objective values '''f''' and constraint values '''g''': While bjectives are to be minimized (<code>min('''f''')</code>), constraints are to be fulfilled (<code>'''g''' =< 0</code>). 0. no constraint handling This option turns off the constraint handling. Objective values and constraints are not changed. 1. delete constraints Deletes all constraints. This can be used if the goal is to minimize the objective function(s) only. The objective functions are not changed. 2. Penalty method All objective function values are summed. All violated constraints (i.e. the constraint value is >= 0) are summed and multiplied with a penalty factor <code>p</code>: output = sum_i(f_i) + sum_j(max(g_j,0))*p Increasing the penalty factor <code>p</code> puts more weight on the constraints compared to the objectives. 3. Penalty method This algorithm works only for population based search methods such as CMA-ES. There are 3 steps a. All objective function values are summed: sum_i(f_i) b. All violated constraints (i.e. the constraint value is >= 0) are summed: sum_j(max(g_j,0)) c. Ranking of the solutions according to the Stochastic Ranking ([[#1|1]]) ==Usage== - ==Source Code== https://sourceforge.net/p/opendino/code/HEAD/tree/trunk/src/org/opendino/modules/optim/tools/ConstraintHandler.java ==References== (<span id="1">1</span>) T. P. Runarsson and X. Yao, "Stochastic Ranking for Constrained Evolutionary Optimization", ''IEEE Transactions on Evolutionary Computation'', Vol. 4, No. 3, pp. 284-294, Sep. 2000. 202 201 2015-10-25T18:52:07Z Dirk 2 /* Module Description */ wikitext text/x-wiki ==Summary== Some optimization problems define [[Documentation/Notation#objectives | objectives]] as well as [[Documentation/Notation#constraints | constraints]]. For example, one can set for the optimization problem [[Documentation/Modules/ProblemTruss | <code>ProblemTruss </code>]] the weight of the truss to be minimized, while a constraint is set on the maximum stress and displacement of the truss. This module aggregates objectives and constraints into a single output. ==Properties== ===General=== {| class="wikitable" style="text-align:left" border="2" cellpadding="5" cellspacing="5" |- ! Algorithm | deterministic (as no gradient handling is implemented) |- ! Design Variables | continuous variables, discrete or mixed variables are possible. |- ! Objectives | any number |- ! Constraints | any number |- ! Boundaries | not affected |- ! Initial Search Region | not affected |- ! Typical X | not affected |- ! Initialization | not required |- |} ===Connections=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Starting at his module | One connection of type <code>optimization</code> |- ! Ending at this module | One connection of type <code>optimization</code> |- |} ===Actions=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Name !! Description |- ! - | - |- |} ===Options=== The options are currently described as "pop-up help". ==Module Description== The result of an evaluation of a solution may contain objective values '''f''' and constraint values '''g''': While bjectives are to be minimized (<code>min('''f''')</code>), constraints are to be fulfilled (<code>'''g''' =< 0</code>). '''0. no constraint handling''' This option turns off the constraint handling. Objective values and constraints are not changed. '''1. delete constraints''' Deletes all constraints. This can be used if the goal is to minimize the objective function(s) only. The objective functions are not changed. '''2. Penalty method''' All objective function values are summed. All violated constraints (i.e. the constraint value is >= 0) are summed and multiplied with a penalty factor <code>p</code>: output = sum_i(f_i) + sum_j(max(g_j,0))*p Increasing the penalty factor <code>p</code> puts more weight on the constraints compared to the objectives. '''3. Penalty method''' This algorithm works only for population based search methods such as CMA-ES. There are 3 steps a. All objective function values are summed: sum_i(f_i) b. All violated constraints (i.e. the constraint value is >= 0) are summed: sum_j(max(g_j,0)) c. Ranking of the solutions according to the Stochastic Ranking ([[#1|1]]) ==Usage== - ==Source Code== https://sourceforge.net/p/opendino/code/HEAD/tree/trunk/src/org/opendino/modules/optim/tools/ConstraintHandler.java ==References== (<span id="1">1</span>) T. P. Runarsson and X. Yao, "Stochastic Ranking for Constrained Evolutionary Optimization", ''IEEE Transactions on Evolutionary Computation'', Vol. 4, No. 3, pp. 284-294, Sep. 2000. 203 202 2015-10-25T18:53:19Z Dirk 2 /* Summary */ wikitext text/x-wiki [[Documentation/Modules | << UP TO MODULE OVERVIEW <<]] ==Summary== Some optimization problems define [[Documentation/Notation#objectives | objectives]] as well as [[Documentation/Notation#constraints | constraints]]. For example, one can set for the optimization problem [[Documentation/Modules/ProblemTruss | <code>ProblemTruss </code>]] the weight of the truss to be minimized, while a constraint is set on the maximum stress and displacement of the truss. This module aggregates objectives and constraints into a single output. ==Properties== ===General=== {| class="wikitable" style="text-align:left" border="2" cellpadding="5" cellspacing="5" |- ! Algorithm | deterministic (as no gradient handling is implemented) |- ! Design Variables | continuous variables, discrete or mixed variables are possible. |- ! Objectives | any number |- ! Constraints | any number |- ! Boundaries | not affected |- ! Initial Search Region | not affected |- ! Typical X | not affected |- ! Initialization | not required |- |} ===Connections=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Starting at his module | One connection of type <code>optimization</code> |- ! Ending at this module | One connection of type <code>optimization</code> |- |} ===Actions=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Name !! Description |- ! - | - |- |} ===Options=== The options are currently described as "pop-up help". ==Module Description== The result of an evaluation of a solution may contain objective values '''f''' and constraint values '''g''': While bjectives are to be minimized (<code>min('''f''')</code>), constraints are to be fulfilled (<code>'''g''' =< 0</code>). '''0. no constraint handling''' This option turns off the constraint handling. Objective values and constraints are not changed. '''1. delete constraints''' Deletes all constraints. This can be used if the goal is to minimize the objective function(s) only. The objective functions are not changed. '''2. Penalty method''' All objective function values are summed. All violated constraints (i.e. the constraint value is >= 0) are summed and multiplied with a penalty factor <code>p</code>: output = sum_i(f_i) + sum_j(max(g_j,0))*p Increasing the penalty factor <code>p</code> puts more weight on the constraints compared to the objectives. '''3. Penalty method''' This algorithm works only for population based search methods such as CMA-ES. There are 3 steps a. All objective function values are summed: sum_i(f_i) b. All violated constraints (i.e. the constraint value is >= 0) are summed: sum_j(max(g_j,0)) c. Ranking of the solutions according to the Stochastic Ranking ([[#1|1]]) ==Usage== - ==Source Code== https://sourceforge.net/p/opendino/code/HEAD/tree/trunk/src/org/opendino/modules/optim/tools/ConstraintHandler.java ==References== (<span id="1">1</span>) T. P. Runarsson and X. Yao, "Stochastic Ranking for Constrained Evolutionary Optimization", ''IEEE Transactions on Evolutionary Computation'', Vol. 4, No. 3, pp. 284-294, Sep. 2000. 204 203 2015-10-25T18:54:05Z Dirk 2 wikitext text/x-wiki [[Documentation/Modules | << BACK TO MODULE OVERVIEW <<]] ==Summary== Some optimization problems define [[Documentation/Notation#objectives | objectives]] as well as [[Documentation/Notation#constraints | constraints]]. For example, one can set for the optimization problem [[Documentation/Modules/ProblemTruss | <code>ProblemTruss </code>]] the weight of the truss to be minimized, while a constraint is set on the maximum stress and displacement of the truss. This module aggregates objectives and constraints into a single output. ==Properties== ===General=== {| class="wikitable" style="text-align:left" border="2" cellpadding="5" cellspacing="5" |- ! Algorithm | deterministic (as no gradient handling is implemented) |- ! Design Variables | continuous variables, discrete or mixed variables are possible. |- ! Objectives | any number |- ! Constraints | any number |- ! Boundaries | not affected |- ! Initial Search Region | not affected |- ! Typical X | not affected |- ! Initialization | not required |- |} ===Connections=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Starting at his module | One connection of type <code>optimization</code> |- ! Ending at this module | One connection of type <code>optimization</code> |- |} ===Actions=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Name !! Description |- ! - | - |- |} ===Options=== The options are currently described as "pop-up help". ==Module Description== The result of an evaluation of a solution may contain objective values '''f''' and constraint values '''g''': While bjectives are to be minimized (<code>min('''f''')</code>), constraints are to be fulfilled (<code>'''g''' =< 0</code>). '''0. no constraint handling''' This option turns off the constraint handling. Objective values and constraints are not changed. '''1. delete constraints''' Deletes all constraints. This can be used if the goal is to minimize the objective function(s) only. The objective functions are not changed. '''2. Penalty method''' All objective function values are summed. All violated constraints (i.e. the constraint value is >= 0) are summed and multiplied with a penalty factor <code>p</code>: output = sum_i(f_i) + sum_j(max(g_j,0))*p Increasing the penalty factor <code>p</code> puts more weight on the constraints compared to the objectives. '''3. Penalty method''' This algorithm works only for population based search methods such as CMA-ES. There are 3 steps a. All objective function values are summed: sum_i(f_i) b. All violated constraints (i.e. the constraint value is >= 0) are summed: sum_j(max(g_j,0)) c. Ranking of the solutions according to the Stochastic Ranking ([[#1|1]]) ==Usage== - ==Source Code== https://sourceforge.net/p/opendino/code/HEAD/tree/trunk/src/org/opendino/modules/optim/tools/ConstraintHandler.java ==References== (<span id="1">1</span>) T. P. Runarsson and X. Yao, "Stochastic Ranking for Constrained Evolutionary Optimization", ''IEEE Transactions on Evolutionary Computation'', Vol. 4, No. 3, pp. 284-294, Sep. 2000. 0 19 205 48 2015-10-25T18:54:45Z Dirk 2 /* Source Code */ wikitext text/x-wiki ==Summary== The module <code>ProblemSimple</code> contains a very simple optimization problem, which can be used to illustrate the optimization process. It contains a time delay, which allows to reduce the speed of evaluations. This can be used e.g. to show the convergence of an optimization algorithm in a presentation. ==Properties== ===General=== {| class="wikitable" style="text-align:left" border="2" cellpadding="5" cellspacing="5" |- ! Algorithm | deterministic test function. |- ! Design Variables | Continuous, discrete, or mixed variables. |- ! Objectives | single-objective for minimization. |- ! Constraints | none |- ! Boundaries | set to fixed value. |- ! Initial Search Region | not set. |- ! Typical X | not set. |- ! Initialization | sets problem properties. |- |} ===Connections=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Starting at his module | - |- ! Ending at this module | Connections of type <code>optimization</code> |- |} ===Actions=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Name !! Description |- ! - | - |- |} ===Options=== The options are the number of discrete and continuous variables and an optional time delay for per evaluation. ==Module Description== === Computation of the Objective === The single objective function ''f'' is a quadratic function. More precisely, ''f'' is computed as the square of all continuous and discrete variables. ''f''('''x''') = sum_i(x_i²) This function is also referred to as the ''sphere function''. ==Usage== - ==Source Code== https://sourceforge.net/p/opendino/code/HEAD/tree/trunk/src/org/opendino/modules/problems/ProblemSimple.java ==References== - 6 50 206 2015-10-25T19:28:21Z Dirk 2 wikitext text/x-wiki 0 51 207 2015-10-25T19:38:26Z Dirk 2 Created page with "==Summary== The module <code>ProblemTruss</code> contains a multi-objective optimization problem. It implements a simple Finite Element Analysis code for analysing a truss struc..." wikitext text/x-wiki ==Summary== The module <code>ProblemTruss</code> contains a multi-objective optimization problem. It implements a simple Finite Element Analysis code for analysing a truss structure. [[File:ProblemTruss.png|300px]] The truss consists of 10 rods which connect the 6 point (labelled from 0 to 5). At point 0 and 2, a force F=45'000N is applied, which deforms the truss and generates stresses in the 10 rods. The input of this module are the individual cross-sections of the rods (i.e. 10 cross-sections). The output of this modules are 3 values, which can be set either as objectives or constraints: # the weight of the 10 rods of the truss # the maximum stress in a rod # the maximum deflection of a node of the truss. ==Properties== ===General=== {| class="wikitable" style="text-align:left" border="2" cellpadding="5" cellspacing="5" |- ! Algorithm | deterministic test function |- ! Design Variables | 10 continuous variables |- ! Objectives | yes, 3 outputs which can be set either as objectives or constraints. |- ! Constraints | yes, 3 outputs which can be set either as objectives or constraints. |- ! Boundaries | yes, can be set as an option. |- ! Initial Search Region | not set. |- ! Typical X | not set. |- ! Initialization | sets problem properties. |- |} ===Connections=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Starting at his module | - |- ! Ending at this module | Connections of type <code>optimization</code> |- |} ===Actions=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Name !! Description |- ! - | - |- |} ===Options=== The options are currently described as "pop-up help". ==Usage== - ==Source Code== https://sourceforge.net/p/opendino/code/HEAD/tree/trunk/src/org/opendino/modules/problems/ProblemTruss.java ==References== - 208 207 2015-10-25T19:39:39Z Dirk 2 /* Summary */ wikitext text/x-wiki ==Summary== The module <code>ProblemTruss</code> is a multi-objective optimization problem. It implements a simple construction problem with the goal to optimize a truss structure. The module constains a small Finite Element Analysis code for analysing a truss structure. [[File:ProblemTruss.png|300px]] The truss consists of 10 rods which connect the 6 point (labelled from 0 to 5). At point 0 and 2, a force F=45'000N is applied, which deforms the truss and generates stresses in the 10 rods. The input of this module are the individual cross-sections of the rods (i.e. 10 cross-sections). The output of this modules are 3 values, which can be set either as objectives or constraints: # the weight of the 10 rods of the truss # the maximum stress in a rod # the maximum deflection of a node of the truss. ==Properties== ===General=== {| class="wikitable" style="text-align:left" border="2" cellpadding="5" cellspacing="5" |- ! Algorithm | deterministic test function |- ! Design Variables | 10 continuous variables |- ! Objectives | yes, 3 outputs which can be set either as objectives or constraints. |- ! Constraints | yes, 3 outputs which can be set either as objectives or constraints. |- ! Boundaries | yes, can be set as an option. |- ! Initial Search Region | not set. |- ! Typical X | not set. |- ! Initialization | sets problem properties. |- |} ===Connections=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Starting at his module | - |- ! Ending at this module | Connections of type <code>optimization</code> |- |} ===Actions=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Name !! Description |- ! - | - |- |} ===Options=== The options are currently described as "pop-up help". ==Usage== - ==Source Code== https://sourceforge.net/p/opendino/code/HEAD/tree/trunk/src/org/opendino/modules/problems/ProblemTruss.java ==References== - 0 16 209 45 2015-10-25T19:43:10Z Dirk 2 /* Source Code */ wikitext text/x-wiki ==Summary== This optimization module is an implementation of the particle swarm optimization algorithm for single- and multi-objective optimization [[#References | (1)]], however it contains some modifications to the publication. The algorithm reflects the natural movement of flocking birds. The algorithm is elitist: Always the best particles are kept as guides. This algorithm is designed for continuous variables and can not handle discrete problems. Furthermore, the algorithm is implemented for minimizing a single and multiple objective function(s). ==Properties== ===General=== {| class="wikitable" style="text-align:left" border="2" cellpadding="5" cellspacing="5" |- ! Algorithm | stochastic - stochastic adaptation of the velocities. |- ! Design Variables | Written for continuous variables. No discrete or mixed variables are possible. |- ! Objectives | single- and multi-objective for minimization. |- ! Constraint handling | no |- ! Boundary handling | no |- ! Initialization | Requires at least one of the following: initial search region or bounds. |- |} ===Connections=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Starting at this module | Module requires exactly one connection of type <code>optimization</code>. |- ! Ending at this module | - |- |} ===Actions=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Name !! Description |- ! '''Run''' | starts the optimization. |- |} ===Options=== The options are currently described in the pop-up help. ==Module Description== === Initialization === The initial particles are randomly generated within the <code>initial search region</code> (if existing) or otherwise between the <code>bounds</code>. === Optimization === The algorithm contains stochastic processes and operates with a set of particles. Parallelization on the basis of the number of particles is implemented. ==Usage== ... todo ==Source Code== https://sourceforge.net/p/opendino/code/HEAD/tree/trunk/src/org/opendino/modules/optAlg/OptAlgMoPso.java ==References== (1) Sanaz Mostaghim. Multi-Objective Evolutionary Algorithms. Data Structures, Convergence, and Diversity. Paderborn, Germany, November 2004. 0 49 210 204 2015-10-26T21:00:06Z Dirk 2 /* Module Description */ wikitext text/x-wiki [[Documentation/Modules | << BACK TO MODULE OVERVIEW <<]] ==Summary== Some optimization problems define [[Documentation/Notation#objectives | objectives]] as well as [[Documentation/Notation#constraints | constraints]]. For example, one can set for the optimization problem [[Documentation/Modules/ProblemTruss | <code>ProblemTruss </code>]] the weight of the truss to be minimized, while a constraint is set on the maximum stress and displacement of the truss. This module aggregates objectives and constraints into a single output. ==Properties== ===General=== {| class="wikitable" style="text-align:left" border="2" cellpadding="5" cellspacing="5" |- ! Algorithm | deterministic (as no gradient handling is implemented) |- ! Design Variables | continuous variables, discrete or mixed variables are possible. |- ! Objectives | any number |- ! Constraints | any number |- ! Boundaries | not affected |- ! Initial Search Region | not affected |- ! Typical X | not affected |- ! Initialization | not required |- |} ===Connections=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Starting at his module | One connection of type <code>optimization</code> |- ! Ending at this module | One connection of type <code>optimization</code> |- |} ===Actions=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Name !! Description |- ! - | - |- |} ===Options=== The options are currently described as "pop-up help". ==Module Description== The result of an evaluation of a solution may contain objective values '''f''' and constraint values '''g''': While bjectives are to be minimized (<code>min('''f''')</code>), constraints are to be fulfilled (<code>'''g''' =< 0</code>). '''0. No Constraint Handling''' This option turns off the constraint handling. Objective values and constraints are not changed. '''1. Delete Constraints''' Deletes all constraints. This can be used if the goal is to minimize the objective function(s) only. The objective functions are not changed. '''2. Penalty Method''' To each objective function, a penalty (larger or equal to zero) is added. All violated constraints (i.e. the constraint value is >= 0) are summed and multiplied with a penalty factor <code>p</code>: penalized objective i = f_i + sum_j(max(g_j,0))*p Increasing the penalty factor <code>p</code> puts more weight on the constraints compared to the objectives. '''3. Stochastic Ranking''' Limitations: # only for single objective problems # requires population based search methods such as CMA-ES. There are 3 steps Rough Description of Main Steps of Stochastic Ranking ([[#1|1]]) # For each solution, the penalty is computed as the sum of all violated constraints (i.e. the constraint value is >= 0) <code> p = sum_j(max(g_j,0)) </code> as in the Penalty Method. # The solutions of the population are randomly ranked. # Always two adjacent solutions of the population are compared either based on their objective value or based on their penalty. Typically the comparison according to the penalty should have a higher probability of about 60%. The winner of the comparison obtains the better ranking position. # The comparision is repeated several times. ==Usage== - ==Source Code== https://sourceforge.net/p/opendino/code/HEAD/tree/trunk/src/org/opendino/modules/optim/tools/ConstraintHandler.java ==References== (<span id="1">1</span>) T. P. Runarsson and X. Yao, "Stochastic Ranking for Constrained Evolutionary Optimization", ''IEEE Transactions on Evolutionary Computation'', Vol. 4, No. 3, pp. 284-294, Sep. 2000. 0 47 211 145 2015-11-18T22:04:26Z Dirk 2 wikitext text/x-wiki == Download Software == The executable jar file is given at https://sourceforge.net/projects/opendino/files/ == Download Source Code == The software is version controlled using a Subversion (SVN) repository. Source code is located at https://sourceforge.net/p/opendino/code The URL specifies also the download command. In the SVN repository, a "trunk" exist and "branches" might be added. "trunk" contains the main development and should always at least compile and be executable. "branches" are copies of the "trunk" for temporary modifications (see the [http://subversion.apache.org/ subversion homepage]) and should not be downloaded. Downloading requires a [http://subversion.apache.org/ subversion client] or an appropriate plug-in for your IDE. 238 211 2019-04-07T12:28:44Z Admin 1 wikitext text/x-wiki == Download Software == The executable jar file is given at https://sourceforge.net/projects/opendino/files/ == Download Source Code == The software is version controlled using a Subversion (SVN) repository. Source code is located at https://sourceforge.net/p/opendino/code The URL above provides also the the download command (using subversion). In the subversion repository, theres is a "trunk" and "branches". The "trunk" contains the main development and should always at least compilable and executable. "branches" are copies of the "trunk" for temporary modifications (see the [http://subversion.apache.org/ subversion homepage]) and should not be downloaded. Downloading requires a [http://subversion.apache.org/ subversion client] or an appropriate plug-in for your IDE. 5bdf4fac2354a5a6233a0d270a8cd09aee10021b 0 2 212 167 2016-02-18T20:28:28Z Dirk 2 /* Welcome to OpenDino */ wikitext text/x-wiki = Welcome to '''OpenDino''' = '''OpenDino ''' is an open source platform for automated optimization, design of experiment and learning, written in Java. The source code as well as as an executable can be found on [http://sourceforge.net/projects/opendino/ sourceforge]. The source code is structured in 3 layers: A core providing the basic backbone, Modules containing all algorithms, and a graphical user interface (GUI). This simplifies the integration of new algorithms as they are represented by additional "Modules". Implemented Modules * Evolutionary optimization algorithms (CMA-ES, (1+1)-ES, Swarm Algorithms) * Deterministic optimization algorithm (SIMPLEX) * Learning (feed-forward Artificial Neural Net) * Design of Experiments (full factorial design, Latin Hypercube, I-Optimal Design) * Problems (test functions, interface to external programs (solvers), distributed and parallel execution) * Other modules (data storage and visualization) Source Code * http://sourceforge.net/projects/opendino/ Contact: * [mailto:help@opendino.org help@opendino.org] 0 10 213 159 2016-09-15T21:11:40Z Dirk 2 /* Developers' Guide */ wikitext text/x-wiki == Requirements == * [[Documentation/Software/Requirements | Software Requirements]] == Users' Guide == * [[Installation | Installation]] * [[Screenshots | A First Introduction to OpenDino in the Screenshots]] * [[Documentation/Notation | Symbols and Notation]] * [[Documentation/Modules | Module Documentation]] == Theory == * [[Documentation/DoE | Introduction to Design of Experiment]] * [[Documentation/Optimization | Introduction to Automated Optimization]] * [[Documentation/Machine_Learning | Introduction to Machine Learning]] == Developers' Guide == * [[Download | Download]] * [[Documentation/Compiling | Developing and Compiling]] * Concepts behind OpenDino ** [[Documentation/Modules/TheCode | The 3 Main Parts]] ** [[Documentation/Modules/IModule | Interface <code>IModule</code> - The Obligatory Interface for Modules]] ** [[Documentation/Modules/Interfaces | Interfaces of Modules]] ** [[Documentation/Modules/ClassesModules | Abstract Modules and Classes]] == Various == * [[Documentation/Related | Links and Related Software]] 215 213 2016-09-15T21:15:46Z Dirk 2 /* Developers' Guide */ wikitext text/x-wiki == Requirements == * [[Documentation/Software/Requirements | Software Requirements]] == Users' Guide == * [[Installation | Installation]] * [[Screenshots | A First Introduction to OpenDino in the Screenshots]] * [[Documentation/Notation | Symbols and Notation]] * [[Documentation/Modules | Module Documentation]] == Theory == * [[Documentation/DoE | Introduction to Design of Experiment]] * [[Documentation/Optimization | Introduction to Automated Optimization]] * [[Documentation/Machine_Learning | Introduction to Machine Learning]] == Developers' Guide == * [[Download | Download]] * [[Documentation/Compiling | Developing and Compiling]] * Tutorials ** [[Tutorials/UseAsLibrary | Using OpenDino as a Library in other Java Code]] * Concepts behind OpenDino ** [[Documentation/Modules/TheCode | The 3 Main Parts]] ** [[Documentation/Modules/IModule | Interface <code>IModule</code> - The Obligatory Interface for Modules]] ** [[Documentation/Modules/Interfaces | Interfaces of Modules]] ** [[Documentation/Modules/ClassesModules | Abstract Modules and Classes]] == Various == * [[Documentation/Related | Links and Related Software]] 223 215 2016-09-15T21:57:11Z Admin 1 /* Developers' Guide */ wikitext text/x-wiki == Requirements == * [[Documentation/Software/Requirements | Software Requirements]] == Users' Guide == * [[Installation | Installation]] * [[Screenshots | A First Introduction to OpenDino in the Screenshots]] * [[Documentation/Notation | Symbols and Notation]] * [[Documentation/Modules | Module Documentation]] == Theory == * [[Documentation/DoE | Introduction to Design of Experiment]] * [[Documentation/Optimization | Introduction to Automated Optimization]] * [[Documentation/Machine_Learning | Introduction to Machine Learning]] == Developers' Guide == * [[Download | Download]] * [[Documentation/Compiling | Developing and Compiling]] * [[Tutorials | Using OpenDino as a Library in other Java Code]] * Concepts behind OpenDino ** [[Documentation/Modules/TheCode | The 3 Main Parts]] ** [[Documentation/Modules/IModule | Interface <code>IModule</code> - The Obligatory Interface for Modules]] ** [[Documentation/Modules/Interfaces | Interfaces of Modules]] ** [[Documentation/Modules/ClassesModules | Abstract Modules and Classes]] == Various == * [[Documentation/Related | Links and Related Software]] 224 223 2016-09-15T21:57:40Z Admin 1 /* Developers' Guide */ wikitext text/x-wiki == Requirements == * [[Documentation/Software/Requirements | Software Requirements]] == Users' Guide == * [[Installation | Installation]] * [[Screenshots | A First Introduction to OpenDino in the Screenshots]] * [[Documentation/Notation | Symbols and Notation]] * [[Documentation/Modules | Module Documentation]] == Theory == * [[Documentation/DoE | Introduction to Design of Experiment]] * [[Documentation/Optimization | Introduction to Automated Optimization]] * [[Documentation/Machine_Learning | Introduction to Machine Learning]] == Developers' Guide == * [[Download | Download]] * [[Documentation/Compiling | Developing and Compiling]] * [[Tutorials | Tutorials: Using OpenDino as a Library in other Java Code]] * Concepts behind OpenDino ** [[Documentation/Modules/TheCode | The 3 Main Parts]] ** [[Documentation/Modules/IModule | Interface <code>IModule</code> - The Obligatory Interface for Modules]] ** [[Documentation/Modules/Interfaces | Interfaces of Modules]] ** [[Documentation/Modules/ClassesModules | Abstract Modules and Classes]] == Various == * [[Documentation/Related | Links and Related Software]] 0 29 214 38 2016-09-15T21:12:55Z Dirk 2 wikitext text/x-wiki * Compiling: JDK 1.7 or higher * Executing: JRE 1.7 or higher 236 214 2019-04-07T12:24:34Z Admin 1 wikitext text/x-wiki * Compiling: JDK 1.8 or higher * Executing: JRE 1.8 or higher 47af24d995e2f3bf5a48dfe010f14dfc6fc8a1c1 237 236 2019-04-07T12:25:28Z Admin 1 wikitext text/x-wiki OpenOpal is written in Java. The required java revisions are: * Compiling: JDK 1.8 or higher * Executing: JRE 1.8 or higher 0b497a7d8cf2b6542d99da8160289185aedc7dc1 0 52 216 2016-09-15T21:27:46Z Dirk 2 Created page with "= Using OpenDino as a Library in Other Java Code = OpenDino contains a graphical user interface for simple interaction (see e.g. the [Screenshots]). Alternatively, OpenDino can..." wikitext text/x-wiki = Using OpenDino as a Library in Other Java Code = OpenDino contains a graphical user interface for simple interaction (see e.g. the [Screenshots]). Alternatively, OpenDino can be used as a library in other Java programs. All functionality of the software can be used such as the graphical plotting environment in the Module {{{DataViewer}}}. == Tutorials == The tutorials can be directly executed as they are implemented in a Java main method. {| class="wikitable" style="text-align:left" border="2" cellpadding="5" cellspacing="5" |- ! Tutorial ! URL |- | single objective evolutionary optimization with output of the best solution | https://sourceforge.net/p/opendino/code/HEAD/tree/trunk/src/org/opendino/tutorial/TutorialSingleObjectiveOptimization.java |- | multi-objective evolutionary optimization with visualization and data storage | https://sourceforge.net/p/opendino/code/HEAD/tree/trunk/src/org/opendino/tutorial/TutorialMultiObjectiveOptimization.java |} 221 216 2016-09-15T21:56:44Z Admin 1 moved [[Tutorials/UseAsLibrary]] to [[Tutorials]] wikitext text/x-wiki = Using OpenDino as a Library in Other Java Code = OpenDino contains a graphical user interface for simple interaction (see e.g. the [Screenshots]). Alternatively, OpenDino can be used as a library in other Java programs. All functionality of the software can be used such as the graphical plotting environment in the Module {{{DataViewer}}}. == Tutorials == The tutorials can be directly executed as they are implemented in a Java main method. {| class="wikitable" style="text-align:left" border="2" cellpadding="5" cellspacing="5" |- ! Tutorial ! URL |- | single objective evolutionary optimization with output of the best solution | https://sourceforge.net/p/opendino/code/HEAD/tree/trunk/src/org/opendino/tutorial/TutorialSingleObjectiveOptimization.java |- | multi-objective evolutionary optimization with visualization and data storage | https://sourceforge.net/p/opendino/code/HEAD/tree/trunk/src/org/opendino/tutorial/TutorialMultiObjectiveOptimization.java |} 225 221 2016-09-15T21:58:49Z Admin 1 /* Using OpenDino as a Library in Other Java Code */ wikitext text/x-wiki = Using OpenDino as a Library in Other Java Code = OpenDino contains a graphical user interface for simple interaction (see e.g. the [Screenshots]). Alternatively, OpenDino can be used as a library in other Java programs. All functionality of the software can be used such as the graphical plotting environment in the Module {{{DataViewer}}}. == Java Code == The tutorials can be directly executed as they are implemented in a Java main method. {| class="wikitable" style="text-align:left" border="2" cellpadding="5" cellspacing="5" |- ! Tutorial ! URL |- | single objective evolutionary optimization with output of the best solution | https://sourceforge.net/p/opendino/code/HEAD/tree/trunk/src/org/opendino/tutorial/TutorialSingleObjectiveOptimization.java |- | multi-objective evolutionary optimization with visualization and data storage | https://sourceforge.net/p/opendino/code/HEAD/tree/trunk/src/org/opendino/tutorial/TutorialMultiObjectiveOptimization.java |} 226 225 2016-09-15T21:59:05Z Admin 1 /* Java Code */ wikitext text/x-wiki = Using OpenDino as a Library in Other Java Code = OpenDino contains a graphical user interface for simple interaction (see e.g. the [Screenshots]). Alternatively, OpenDino can be used as a library in other Java programs. All functionality of the software can be used such as the graphical plotting environment in the Module {{{DataViewer}}}. === Java Code === The tutorials can be directly executed as they are implemented in a Java main method. {| class="wikitable" style="text-align:left" border="2" cellpadding="5" cellspacing="5" |- ! Tutorial ! URL |- | single objective evolutionary optimization with output of the best solution | https://sourceforge.net/p/opendino/code/HEAD/tree/trunk/src/org/opendino/tutorial/TutorialSingleObjectiveOptimization.java |- | multi-objective evolutionary optimization with visualization and data storage | https://sourceforge.net/p/opendino/code/HEAD/tree/trunk/src/org/opendino/tutorial/TutorialMultiObjectiveOptimization.java |} 0 33 217 62 2016-09-15T21:50:28Z Dirk 2 /* JAVA Implementations */ wikitext text/x-wiki =Links and Related Pages= == JAVA Implementations == * Neural Network and Data Mining ** [http://snarli.sourceforge.net/ SNARLI] ** [http://www.cs.waikato.ac.nz/~ml/weka/ WEKA] ** [http://rapid-i.com/ RapidMiner] == MATLAB Implementations == * Neural Network and Data Mining ** [http://www.esat.kuleuven.ac.be/sista/lssvmlab/ Least Squares Support Vector Machines (LS-SVM)] == Multi-Language Implementations == * Optimization ** [https://www.lri.fr/~hansen/cmaesintro.html Evolution Strategy with Covariance Matrix Adaptation (CMA-ES)] 218 217 2016-09-15T21:51:30Z Dirk 2 /* JAVA Implementations */ wikitext text/x-wiki =Links and Related Pages= == JAVA Implementations == * Optimization Algorithms * Neural Network and Data Mining ** [http://snarli.sourceforge.net/ SNARLI] ** [http://www.cs.waikato.ac.nz/~ml/weka/ WEKA] == MATLAB Implementations == * Neural Network and Data Mining ** [http://www.esat.kuleuven.ac.be/sista/lssvmlab/ Least Squares Support Vector Machines (LS-SVM)] == Multi-Language Implementations == * Optimization ** [https://www.lri.fr/~hansen/cmaesintro.html Evolution Strategy with Covariance Matrix Adaptation (CMA-ES)] 219 218 2016-09-15T21:51:57Z Dirk 2 /* MATLAB Implementations */ wikitext text/x-wiki =Links and Related Pages= == JAVA Implementations == * Optimization Algorithms * Neural Network and Data Mining ** [http://snarli.sourceforge.net/ SNARLI] ** [http://www.cs.waikato.ac.nz/~ml/weka/ WEKA] == Multi-Language Implementations == * Optimization ** [https://www.lri.fr/~hansen/cmaesintro.html Evolution Strategy with Covariance Matrix Adaptation (CMA-ES)] 0 3 220 149 2016-09-15T21:53:02Z Dirk 2 /* References */ wikitext text/x-wiki == The Main Window == After starting software, the main '''GUI''' appears (Fig. 1). The figure contains an example for an optimization using 4 '''Module'''s. Each module has a name and an unique ID. The software is a strictly modular. All functionality for automated optimization and machine learning is encoded in the modules. Here: Module 1 (<code>OptAlgCMA</code>) is an optimization algorithm. It is connected via Module 3 (<code>Protocoller</code>) with Module 2 (<code>ProblemSimple</code>). Module 2 contains the optimization problem, i.e. the function to minimize. Here, it is a simple continuous, quadratic function. Module 3 (<code>Protocoller</code>) is a protocoling module, i.e. it stores all evaluated solutions of an optimization run. These solutions can be visualized with Module 4 (<code>DataViewer</code>). [[Image:MainGUI.png|frame|center|Figure 1: Main GUI of OpenDino]] == Adding, Editing, and Connecting Modules == Right-clicking on the dotted area or on a module opens a dialogue as shown in Fig. 2. This dialogue supports: * adding modules (if clicked on a free space) * removing modules or changing the options of a module when clicking on a module * adding/removing connections between modules * checking and running modules In Fig. 2, the right-click is made on Module 4, e.g. for setting the options of this module. [[Image:ModuleRightclick.png|frame|center|Figure 2: Editing Modules]] == Running an Optimization == Right-clicking Module 1 and selecting the option <code>Run</code> starts an optimization. The standard output of the optimization is given in the lower part of the main window in Fig. 3. [[Image:Optimization.png|frame|center|Figure 3: Running an Optimization]] == Postprocessing an Optimization == Right-clicking Module 4 and selecting the option <code>Run</code> starts an the data viewer. Figure 4 shows the evolution of the objective function ''f'' over the number of evaluations. As the objective function is a simple quadratic function (x^2), the minimal function value is zero, which is approximated by 1e-12. [[Image:DataViewer.png|frame|center|Figure 4: Postprocessing an Optimization with the DataViewer module. ]] 239 220 2019-04-07T12:29:48Z Admin 1 wikitext text/x-wiki == The Main Window == After starting software, the main '''GUI''' appears (Fig. 1). The figure contains an example for an optimization using 4 '''Module'''s. Each module has a name and an unique ID. The software is strictly modular. All functionality for automated optimization and machine learning is encoded in the modules. Here: Module 1 (<code>OptAlgCMA</code>) is an optimization algorithm. It is connected via Module 3 (<code>Protocoller</code>) with Module 2 (<code>ProblemSimple</code>). Module 2 contains the optimization problem, i.e. the function to minimize. Here, it is a simple continuous, quadratic function. Module 3 (<code>Protocoller</code>) is a protocoling module, i.e. it stores all evaluated solutions of an optimization run. These solutions can be visualized with Module 4 (<code>DataViewer</code>). [[Image:MainGUI.png|frame|center|Figure 1: Main GUI of OpenDino]] == Adding, Editing, and Connecting Modules == Right-clicking on the dotted area or on a module opens a dialogue as shown in Fig. 2. This dialogue supports: * adding modules (if clicked on a free space) * removing modules or changing the options of a module when clicking on a module * adding/removing connections between modules * checking and running modules In Fig. 2, the right-click is made on Module 4, e.g. for setting the options of this module. [[Image:ModuleRightclick.png|frame|center|Figure 2: Editing Modules]] == Running an Optimization == Right-clicking Module 1 and selecting the option <code>Run</code> starts an optimization. The standard output of the optimization is given in the lower part of the main window in Fig. 3. [[Image:Optimization.png|frame|center|Figure 3: Running an Optimization]] == Postprocessing an Optimization == Right-clicking Module 4 and selecting the option <code>Run</code> starts an the data viewer. Figure 4 shows the evolution of the objective function ''f'' over the number of evaluations. As the objective function is a simple quadratic function (x^2), the minimal function value is zero, which is approximated by 1e-12. [[Image:DataViewer.png|frame|center|Figure 4: Postprocessing an Optimization with the DataViewer module. ]] 5582b0861ad3166b37d0a6a8adfa1ce20d505eda 0 53 222 2016-09-15T21:56:44Z Admin 1 moved [[Tutorials/UseAsLibrary]] to [[Tutorials]] wikitext text/x-wiki #REDIRECT [[Tutorials]] 8 54 227 2017-02-18T22:45:45Z Admin 1 Die Seite wurde neu angelegt: „Main_Page“ wikitext text/x-wiki Main_Page 8f9e9b397d590520d0938b3a063c1c0b58ba8445 8 55 228 2017-02-18T22:49:53Z Admin 1 Die Seite wurde neu angelegt: „Download“ wikitext text/x-wiki Download a479c9c34e878d07b4d67a73a48f432ad7dc53c8 0 40 231 148 2019-04-05T20:35:46Z Admin 1 wikitext text/x-wiki == Download == The compiled software can be downloaded from [[Download]] page. As the software is written in Java, the compiled code runs on most platforms. The software consists of a single jar file <tt>opendino.jar</tt>. == Start == Start OpenDino with either: * double clicking on the jar (this is simple, however, not activated on all plattforms and console output may not be seen). * open a Linux shell or Windows Command Line and enter one of the following two command in the same directory as file <tt>opendino.jar</tt> was downloaded (Windows often requires the latter command). <pre>$ java -jar opendino.jar </pre> <pre>$ java -classpath opendino.jar org.opendino.core.OpenDino</pre> * to see additional command line options enter <pre>$ java -jar opendino.jar -help </pre> == Writing a Shell Script == The script assumes an OpenDino archive file <tt>opendino.jar</tt>. This filename can be replaced to match the actual name or by a filename with absolute path. For '''Windows''', create a file <tt>opendino.bat</tt> with the following content: java -cp opendino.jar org/opendino/core/OpenDino %* For '''Linux''', create a file <tt>opendino.sh</tt> with the following content: #!/bin/sh java -classpath opendino.jar org.opendino.core.OpenDino $* To make the file executable enter in the shell: chmod u+x opendino.sh da35d95e5133660fb5c3feadb00b99d5a7dc993e 232 231 2019-04-05T20:45:53Z Admin 1 wikitext text/x-wiki == Download == The compiled software can be downloaded from [[Download]] page. As the software is written in Java, the compiled code runs on most platforms. The software consists of a single jar file <tt>opendino.jar</tt>. == Start == Start OpenDino with either: * double clicking on the jar (this is simple, however, not activated on all platforms and console output may not be seen). * open a Linux shell or Windows Command Line and enter one of the following two command in the same directory as file <tt>opendino.jar</tt> was downloaded (Windows often requires the latter command). <pre>$ java -jar opendino.jar </pre> <pre>$ java -classpath opendino.jar org.opendino.core.OpenDino</pre> * to see additional command line options enter <pre>$ java -jar opendino.jar -help </pre> == Writing a Shell Script == The script assumes an OpenDino archive file <tt>opendino.jar</tt>. This filename can be replaced to match the actual name or by a filename with absolute path. For '''Windows''', create a file <tt>opendino.bat</tt> with the following content: java -cp opendino.jar org/opendino/core/OpenDino %* For '''Linux''', create a file <tt>opendino.sh</tt> with the following content: #!/bin/sh java -classpath opendino.jar org.opendino.core.OpenDino $* To make the file executable enter in the shell: chmod u+x opendino.sh 19f1548cdffad771636ce5278fcedb266d3e4449 233 232 2019-04-05T20:50:36Z Admin 1 wikitext text/x-wiki == Download == The compiled software can be downloaded from [[Download]] page. As the software is written in Java, the compiled code runs on most platforms. The software consists of a single jar file <tt>opendino.jar</tt>. == Running OpenDino == Start OpenDino with either: * double clicking on the jar (this is simple, however, not activated on all platforms and console output may not be seen). * open a Linux shell or Windows Command Line and enter one of the following two command in the same directory as file <tt>opendino.jar</tt> was downloaded (Windows often requires the latter command). <pre>$ java -jar opendino.jar </pre> <pre>$ java -classpath opendino.jar org.opendino.core.OpenDino</pre> * to see additional command line options enter <pre>$ java -jar opendino.jar -help </pre> == Writing a Shell Script == The script assumes an OpenDino archive file <tt>opendino.jar</tt>. This filename can be replaced to match the actual name or by a filename with absolute path. For '''Windows''', create a file <tt>opendino.bat</tt> with the following content: java -cp opendino.jar org/opendino/core/OpenDino %* For '''Linux''', create a file <tt>opendino.sh</tt> with the following content: #!/bin/sh java -classpath opendino.jar org.opendino.core.OpenDino $* To make the file executable enter in the shell: chmod u+x opendino.sh ff6793a9ebed385a7cdd30b4965a8bee3e6532e6 234 233 2019-04-05T20:50:51Z Admin 1 /* Running OpenDino */ wikitext text/x-wiki == Download == The compiled software can be downloaded from [[Download]] page. As the software is written in Java, the compiled code runs on most platforms. The software consists of a single jar file <tt>opendino.jar</tt>. == Running OpenDino == Start OpenDino by either: * double clicking on the jar (this is simple, however, not activated on all platforms and console output may not be seen). * open a Linux shell or Windows Command Line and enter one of the following two command in the same directory as file <tt>opendino.jar</tt> was downloaded (Windows often requires the latter command). <pre>$ java -jar opendino.jar </pre> <pre>$ java -classpath opendino.jar org.opendino.core.OpenDino</pre> * to see additional command line options enter <pre>$ java -jar opendino.jar -help </pre> == Writing a Shell Script == The script assumes an OpenDino archive file <tt>opendino.jar</tt>. This filename can be replaced to match the actual name or by a filename with absolute path. For '''Windows''', create a file <tt>opendino.bat</tt> with the following content: java -cp opendino.jar org/opendino/core/OpenDino %* For '''Linux''', create a file <tt>opendino.sh</tt> with the following content: #!/bin/sh java -classpath opendino.jar org.opendino.core.OpenDino $* To make the file executable enter in the shell: chmod u+x opendino.sh 2208b84db6276bee0e047e4b93b75c7bfa4a1864 235 234 2019-04-05T20:56:40Z Admin 1 /* Writing a Shell Script */ wikitext text/x-wiki == Download == The compiled software can be downloaded from [[Download]] page. As the software is written in Java, the compiled code runs on most platforms. The software consists of a single jar file <tt>opendino.jar</tt>. == Running OpenDino == Start OpenDino by either: * double clicking on the jar (this is simple, however, not activated on all platforms and console output may not be seen). * open a Linux shell or Windows Command Line and enter one of the following two command in the same directory as file <tt>opendino.jar</tt> was downloaded (Windows often requires the latter command). <pre>$ java -jar opendino.jar </pre> <pre>$ java -classpath opendino.jar org.opendino.core.OpenDino</pre> * to see additional command line options enter <pre>$ java -jar opendino.jar -help </pre> == Writing a Shell Script == The script assumes an OpenDino archive file <tt>opendino.jar</tt>. For '''Windows''', create a file <tt>opendino.bat</tt> with the following content: java -cp opendino.jar org/opendino/core/OpenDino %* To use the batch file also from different directories, use the absolute path, e.g.: java -cp C:\Programs\opendino.jar org/opendino/core/OpenDino %* Now you can also double click project files (*.opl). When Windows ask for the program/app to open this file, choose the batch file written above. For '''Linux''', create a file <tt>opendino.sh</tt> with the following content: #!/bin/sh java -classpath opendino.jar org.opendino.core.OpenDino $* To make the file executable enter in the shell: chmod u+x opendino.sh 55ce64450e075d47a51f453030687b71c4b6f02d 0 26 240 183 2019-04-07T12:31:38Z Admin 1 wikitext text/x-wiki == Notation == As a maths parser is currently not used in this Wiki, we write math equations as formatted text: * Scalars are written as small italic letters, e.g. ''f'' * Vectors are written as small bold letters, e.g. '''x'''. * Matrices are written in capital bold letters, e.g. '''C'''. == Symbols == :{| cellpadding="5" width="95%" |- | ''a'', '''a''' | additionals, i.e. additional value(s) |- | ''f'', '''f''' | objective function(s) |- | ''g'', '''g''' | constraint(s) |- | ''x'', '''x''' | design variable(s) |- |} == Terminology == :{| cellpadding="5" cellspacing="0" width="95%" border="1" |- | ''additionals'' <div id="additionals"></div> | Additionals '''a''' are additional values in a '''solution''' that are for information only and do not influence the optimization. For example, if an optimization problem returns an objective function that is a sum of several values, these values could be added to the solution as additional values '''a'''. |- | ''constraints'' <div id="constraints"></div> | Constraints '''g''' are criteria that have to be fulfilled. OpenDino defines a constraint ''g'' as * fulfilled, if ''g'' =< 0 * violated, if ''g'' > 0. The most simple constraint handling in optimization is to add a penalty to the objective function if the constraint is vialoted, resulting in ''f'' + max(0, ''g''). |- | ''design variables'' <div id="design_variables"></div> | The vector of design variables '''x''' may consist of real numbers (continuous variables), integers (discrete variables) or both (mixed variables). |- | ''objectives'' <div id="objectives"></div> | An optimization problem must have at least one objective or one constraint. OpenDino requires that the objective(s) '''f''' is/are to be minimized. A maximization of a function ''k'' can be converted into minimization by using ''f'' = -''k''. |- | ''solution'' <div id="solution"></div> | The term solution is used in optimization. One solution ('''x''','''f''','''g''','''a''') consists of a vector of design variables '''x''', the evaluated objective(s) '''f'''('''x'''), constraint(s) '''g'''('''x'''), and optionally of additional values '''a'''. |-|} 26fa4af1f5e30b87ca8136bef50e7ebbc5ccbec4 0 58 241 2019-04-07T13:06:16Z Admin 1 Die Seite wurde neu angelegt: „==Summary== The module <code>ContinuousMOTestProblems</code> contains a set of multi-objective optimization problesm, which can be used to test optimization a…“ wikitext text/x-wiki ==Summary== The module <code>ContinuousMOTestProblems</code> contains a set of multi-objective optimization problesm, which can be used to test optimization algorithms. ==Properties== ===General=== {| class="wikitable" style="text-align:left" border="2" cellpadding="5" cellspacing="5" |- ! Algorithm | deterministic test function |- ! Design Variables | Continuous design variables only |- ! Objectives | multi-objective for minimization |- ! Constraints | none |- ! Boundaries | problem dependent |- ! Initial Search Region | problem dependent |- ! Typical X | not set. |- |} ===Connections=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Starting at his module | none |- ! Ending at this module | Connections of type <code>optimization</code> |- |} ===Actions=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Name !! Description |- ! none | - |- |} ===Options=== The options are the number of discrete and continuous variables and an optional time delay for per evaluation. ==Module Description== === Computation of the Objective === The single objective function ''f'' is a quadratic function. More precisely, ''f'' is computed as the square of all continuous and discrete variables. ''f''('''x''') = sum_i(x_i²) This function is also referred to as the ''sphere function''. ==Usage== - ==Source Code== https://sourceforge.net/p/opendino/code/HEAD/tree/trunk/src/org/opendino/modules/problems/ProblemSimple.java ==References== - 08a8758828b3f9c83fe85d3ff96bac292e6eec4a 242 241 2019-04-07T13:06:40Z Admin 1 /* Actions */ wikitext text/x-wiki ==Summary== The module <code>ContinuousMOTestProblems</code> contains a set of multi-objective optimization problesm, which can be used to test optimization algorithms. ==Properties== ===General=== {| class="wikitable" style="text-align:left" border="2" cellpadding="5" cellspacing="5" |- ! Algorithm | deterministic test function |- ! Design Variables | Continuous design variables only |- ! Objectives | multi-objective for minimization |- ! Constraints | none |- ! Boundaries | problem dependent |- ! Initial Search Region | problem dependent |- ! Typical X | not set. |- |} ===Connections=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Starting at his module | none |- ! Ending at this module | Connections of type <code>optimization</code> |- |} ===Actions=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Name !! Description |- ! - | - |- |} ===Options=== The options are the number of discrete and continuous variables and an optional time delay for per evaluation. ==Module Description== === Computation of the Objective === The single objective function ''f'' is a quadratic function. More precisely, ''f'' is computed as the square of all continuous and discrete variables. ''f''('''x''') = sum_i(x_i²) This function is also referred to as the ''sphere function''. ==Usage== - ==Source Code== https://sourceforge.net/p/opendino/code/HEAD/tree/trunk/src/org/opendino/modules/problems/ProblemSimple.java ==References== - 0546f8d452da5c8dd0aa67f30e19ce8890af95a8 243 242 2019-04-07T13:07:13Z Admin 1 /* Source Code */ wikitext text/x-wiki ==Summary== The module <code>ContinuousMOTestProblems</code> contains a set of multi-objective optimization problesm, which can be used to test optimization algorithms. ==Properties== ===General=== {| class="wikitable" style="text-align:left" border="2" cellpadding="5" cellspacing="5" |- ! Algorithm | deterministic test function |- ! Design Variables | Continuous design variables only |- ! Objectives | multi-objective for minimization |- ! Constraints | none |- ! Boundaries | problem dependent |- ! Initial Search Region | problem dependent |- ! Typical X | not set. |- |} ===Connections=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Starting at his module | none |- ! Ending at this module | Connections of type <code>optimization</code> |- |} ===Actions=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Name !! Description |- ! - | - |- |} ===Options=== The options are the number of discrete and continuous variables and an optional time delay for per evaluation. ==Module Description== === Computation of the Objective === The single objective function ''f'' is a quadratic function. More precisely, ''f'' is computed as the square of all continuous and discrete variables. ''f''('''x''') = sum_i(x_i²) This function is also referred to as the ''sphere function''. ==Usage== - ==Source Code== https://sourceforge.net/p/opendino/code/HEAD/tree/trunk/src/org/opendino/modules/problems/ProblemMOTestProblems.java ==References== - f5836977a5282b143cf423cd7f7d658c2a8b5d61 244 243 2019-04-07T13:07:52Z Admin 1 /* Source Code */ wikitext text/x-wiki ==Summary== The module <code>ContinuousMOTestProblems</code> contains a set of multi-objective optimization problesm, which can be used to test optimization algorithms. ==Properties== ===General=== {| class="wikitable" style="text-align:left" border="2" cellpadding="5" cellspacing="5" |- ! Algorithm | deterministic test function |- ! Design Variables | Continuous design variables only |- ! Objectives | multi-objective for minimization |- ! Constraints | none |- ! Boundaries | problem dependent |- ! Initial Search Region | problem dependent |- ! Typical X | not set. |- |} ===Connections=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Starting at his module | none |- ! Ending at this module | Connections of type <code>optimization</code> |- |} ===Actions=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Name !! Description |- ! - | - |- |} ===Options=== The options are the number of discrete and continuous variables and an optional time delay for per evaluation. ==Module Description== === Computation of the Objective === The single objective function ''f'' is a quadratic function. More precisely, ''f'' is computed as the square of all continuous and discrete variables. ''f''('''x''') = sum_i(x_i²) This function is also referred to as the ''sphere function''. ==Usage== - ==Source Code== https://sourceforge.net/p/opendino/code/HEAD/tree/trunk/src/org/opendino/modules/problems/ContinuousMOTestProblems.java ==References== - 579464d8003ce0f3c0bec38e68f0b23010d01c47 245 244 2019-04-07T13:08:17Z Admin 1 /* Summary */ wikitext text/x-wiki ==Summary== The module <code>ContinuousMOTestProblems</code> contains a set of multi-objective optimization problems, which can be used to test optimization algorithms. ==Properties== ===General=== {| class="wikitable" style="text-align:left" border="2" cellpadding="5" cellspacing="5" |- ! Algorithm | deterministic test function |- ! Design Variables | Continuous design variables only |- ! Objectives | multi-objective for minimization |- ! Constraints | none |- ! Boundaries | problem dependent |- ! Initial Search Region | problem dependent |- ! Typical X | not set. |- |} ===Connections=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Starting at his module | none |- ! Ending at this module | Connections of type <code>optimization</code> |- |} ===Actions=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Name !! Description |- ! - | - |- |} ===Options=== The options are the number of discrete and continuous variables and an optional time delay for per evaluation. ==Module Description== === Computation of the Objective === The single objective function ''f'' is a quadratic function. More precisely, ''f'' is computed as the square of all continuous and discrete variables. ''f''('''x''') = sum_i(x_i²) This function is also referred to as the ''sphere function''. ==Usage== - ==Source Code== https://sourceforge.net/p/opendino/code/HEAD/tree/trunk/src/org/opendino/modules/problems/ContinuousMOTestProblems.java ==References== - 1284d202c86bc9dd74bdb238423767077f279431 246 245 2019-04-07T13:08:40Z Admin 1 /* General */ wikitext text/x-wiki ==Summary== The module <code>ContinuousMOTestProblems</code> contains a set of multi-objective optimization problems, which can be used to test optimization algorithms. ==Properties== ===General=== {| class="wikitable" style="text-align:left" border="2" cellpadding="5" cellspacing="5" |- ! Algorithm | deterministic test function |- ! Design Variables | continuous design variables only |- ! Objectives | multi-objective for minimization |- ! Constraints | none |- ! Boundaries | problem dependent |- ! Initial Search Region | problem dependent |- ! Typical X | not set |- |} ===Connections=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Starting at his module | none |- ! Ending at this module | Connections of type <code>optimization</code> |- |} ===Actions=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Name !! Description |- ! - | - |- |} ===Options=== The options are the number of discrete and continuous variables and an optional time delay for per evaluation. ==Module Description== === Computation of the Objective === The single objective function ''f'' is a quadratic function. More precisely, ''f'' is computed as the square of all continuous and discrete variables. ''f''('''x''') = sum_i(x_i²) This function is also referred to as the ''sphere function''. ==Usage== - ==Source Code== https://sourceforge.net/p/opendino/code/HEAD/tree/trunk/src/org/opendino/modules/problems/ContinuousMOTestProblems.java ==References== - 95e1846bae1ee902d17ec0c8eefd1ff9392c409a 247 246 2019-04-07T13:10:33Z Admin 1 /* Computation of the Objective */ wikitext text/x-wiki ==Summary== The module <code>ContinuousMOTestProblems</code> contains a set of multi-objective optimization problems, which can be used to test optimization algorithms. ==Properties== ===General=== {| class="wikitable" style="text-align:left" border="2" cellpadding="5" cellspacing="5" |- ! Algorithm | deterministic test function |- ! Design Variables | continuous design variables only |- ! Objectives | multi-objective for minimization |- ! Constraints | none |- ! Boundaries | problem dependent |- ! Initial Search Region | problem dependent |- ! Typical X | not set |- |} ===Connections=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Starting at his module | none |- ! Ending at this module | Connections of type <code>optimization</code> |- |} ===Actions=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Name !! Description |- ! - | - |- |} ===Options=== The options are the number of discrete and continuous variables and an optional time delay for per evaluation. ==Module Description== === Multi-Objective Sphere === The multi-objective sphere function '''f''' is a set of quadratic functions. More precisely, each ''f<sub>i'' is computed as the square of all continuous variables. ''f_i''('''x''') = sum_i(x_i²) This function is also referred to as the ''sphere function''. ==Usage== - ==Source Code== https://sourceforge.net/p/opendino/code/HEAD/tree/trunk/src/org/opendino/modules/problems/ContinuousMOTestProblems.java ==References== - c136e8c434fdf9c836895744805546db73846515 248 247 2019-04-07T13:14:30Z Admin 1 /* Multi-Objective Sphere */ wikitext text/x-wiki ==Summary== The module <code>ContinuousMOTestProblems</code> contains a set of multi-objective optimization problems, which can be used to test optimization algorithms. ==Properties== ===General=== {| class="wikitable" style="text-align:left" border="2" cellpadding="5" cellspacing="5" |- ! Algorithm | deterministic test function |- ! Design Variables | continuous design variables only |- ! Objectives | multi-objective for minimization |- ! Constraints | none |- ! Boundaries | problem dependent |- ! Initial Search Region | problem dependent |- ! Typical X | not set |- |} ===Connections=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Starting at his module | none |- ! Ending at this module | Connections of type <code>optimization</code> |- |} ===Actions=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Name !! Description |- ! - | - |- |} ===Options=== The options are the number of discrete and continuous variables and an optional time delay for per evaluation. ==Module Description== === Multi-Objective Sphere === The multi-objective sphere function '''f''' is a set of quadratic functions. More precisely, each ''f<sub>i'' is computed as the square of all continuous variables. ''f_i''('''x''') = ''x_i''² + sum_{''j, j~=i''} (x_''j''²) This function is also referred to as the ''sphere function''. ==Usage== - ==Source Code== https://sourceforge.net/p/opendino/code/HEAD/tree/trunk/src/org/opendino/modules/problems/ContinuousMOTestProblems.java ==References== - 33ed99cb6d96f49629602e32dd42ef50f701cc0e 249 248 2019-04-07T13:19:00Z Admin 1 /* Multi-Objective Sphere */ wikitext text/x-wiki ==Summary== The module <code>ContinuousMOTestProblems</code> contains a set of multi-objective optimization problems, which can be used to test optimization algorithms. ==Properties== ===General=== {| class="wikitable" style="text-align:left" border="2" cellpadding="5" cellspacing="5" |- ! Algorithm | deterministic test function |- ! Design Variables | continuous design variables only |- ! Objectives | multi-objective for minimization |- ! Constraints | none |- ! Boundaries | problem dependent |- ! Initial Search Region | problem dependent |- ! Typical X | not set |- |} ===Connections=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Starting at his module | none |- ! Ending at this module | Connections of type <code>optimization</code> |- |} ===Actions=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Name !! Description |- ! - | - |- |} ===Options=== The options are the number of discrete and continuous variables and an optional time delay for per evaluation. ==Module Description== === Multi-Objective Sphere === The multi-objective sphere function '''f''' is a set of quadratic functions. More precisely, each ''f<sub>i'' is computed as the square of all continuous variables. ''f_i''('''x''') = (''x_i'' - 1)² + sum_{''j, j~=i''} (x_''j''²) For example ''f₁''('''x''') = (''x₁'' - 1)² + ''x''₂<sup>2 + ''x''₃<sup>2 + ... ''f₂''('''x''') = ''x₁'' ² + (''x₂'' - 1)² + ''x''₃<sup>2 + ... ... ==Usage== - ==Source Code== https://sourceforge.net/p/opendino/code/HEAD/tree/trunk/src/org/opendino/modules/problems/ContinuousMOTestProblems.java ==References== - f2c680a1b972bae32f4e5b32fec5c71e5915538a 250 249 2019-04-07T13:31:13Z Admin 1 /* Multi-Objective Sphere */ wikitext text/x-wiki ==Summary== The module <code>ContinuousMOTestProblems</code> contains a set of multi-objective optimization problems, which can be used to test optimization algorithms. ==Properties== ===General=== {| class="wikitable" style="text-align:left" border="2" cellpadding="5" cellspacing="5" |- ! Algorithm | deterministic test function |- ! Design Variables | continuous design variables only |- ! Objectives | multi-objective for minimization |- ! Constraints | none |- ! Boundaries | problem dependent |- ! Initial Search Region | problem dependent |- ! Typical X | not set |- |} ===Connections=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Starting at his module | none |- ! Ending at this module | Connections of type <code>optimization</code> |- |} ===Actions=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Name !! Description |- ! - | - |- |} ===Options=== The options are the number of discrete and continuous variables and an optional time delay for per evaluation. ==Module Description== === Multi-Objective Sphere === The multi-objective sphere function '''f''' is a set of quadratic functions. More precisely, each ''f<sub>i'' is computed as the square of all continuous variables. ''f_i''('''x''') = (''x_i'' - 1)² + sum_{''j, j~=i''} (x_''j''²) For example ''f₁''('''x''') = (''x₁'' - 1)² + ''x''₂² + ''x''₃<sup>2 + ... ''f₂''('''x''') = ''x₁''² + (''x₂'' - 1)² + ''x''₃<sup>2 + ... ... The Pareto front for the two-objective case is given in the following picture: ==Usage== - ==Source Code== https://sourceforge.net/p/opendino/code/HEAD/tree/trunk/src/org/opendino/modules/problems/ContinuousMOTestProblems.java ==References== - d8a55029be93a4a4db2247f82bbeaafd51d02cf5 252 250 2019-04-07T13:53:58Z Admin 1 /* Multi-Objective Sphere */ wikitext text/x-wiki ==Summary== The module <code>ContinuousMOTestProblems</code> contains a set of multi-objective optimization problems, which can be used to test optimization algorithms. ==Properties== ===General=== {| class="wikitable" style="text-align:left" border="2" cellpadding="5" cellspacing="5" |- ! Algorithm | deterministic test function |- ! Design Variables | continuous design variables only |- ! Objectives | multi-objective for minimization |- ! Constraints | none |- ! Boundaries | problem dependent |- ! Initial Search Region | problem dependent |- ! Typical X | not set |- |} ===Connections=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Starting at his module | none |- ! Ending at this module | Connections of type <code>optimization</code> |- |} ===Actions=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Name !! Description |- ! - | - |- |} ===Options=== The options are the number of discrete and continuous variables and an optional time delay for per evaluation. ==Module Description== === Multi-Objective Sphere === The multi-objective sphere function '''f''' is a set of quadratic functions. More precisely, each ''f<sub>i'' is computed as the square of all continuous variables. ''f_i''('''x''') = (''x_i'' - 1)² + sum_{''j, j~=i''} (x_''j''²) For example ''f₁''('''x''') = (''x₁'' - 1)² + ''x''₂² + ''x''₃<sup>2 + ... ''f₂''('''x''') = ''x₁''² + (''x₂'' - 1)² + ''x''₃<sup>2 + ... ... The Pareto front for the two-objective case is given in the following picture: [[Image:moo_sphere.png|frame|center|10px|Pareto front of the multi-objective sphere function]] ==Usage== - ==Source Code== https://sourceforge.net/p/opendino/code/HEAD/tree/trunk/src/org/opendino/modules/problems/ContinuousMOTestProblems.java ==References== - 415d7f6afcde6f9f068b10531978450c6976af59 254 252 2019-04-07T16:20:07Z Admin 1 /* Multi-Objective Sphere */ wikitext text/x-wiki ==Summary== The module <code>ContinuousMOTestProblems</code> contains a set of multi-objective optimization problems, which can be used to test optimization algorithms. ==Properties== ===General=== {| class="wikitable" style="text-align:left" border="2" cellpadding="5" cellspacing="5" |- ! Algorithm | deterministic test function |- ! Design Variables | continuous design variables only |- ! Objectives | multi-objective for minimization |- ! Constraints | none |- ! Boundaries | problem dependent |- ! Initial Search Region | problem dependent |- ! Typical X | not set |- |} ===Connections=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Starting at his module | none |- ! Ending at this module | Connections of type <code>optimization</code> |- |} ===Actions=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Name !! Description |- ! - | - |- |} ===Options=== The options are the number of discrete and continuous variables and an optional time delay for per evaluation. ==Module Description== === Multi-Objective Sphere === The multi-objective sphere function '''f''' is a set of quadratic functions. More precisely, each ''f<sub>i'' is computed as the square of all continuous variables. ''f_i''('''x''') = (''x_i'' - 1)² + sum_{''j, j~=i''} (x_''j''²) For example ''f₁''('''x''') = (''x₁'' - 1)² + ''x''₂² + ''x''₃<sup>2 + ... ''f₂''('''x''') = ''x₁''² + (''x₂'' - 1)² + ''x''₃<sup>2 + ... ... The Pareto front for the two-objective case is given in the following picture: [[Image:moo_sphere.png|100x100px|center|thumb|300x300px|Pareto front of the multi-objective sphere function]] ==Usage== - ==Source Code== https://sourceforge.net/p/opendino/code/HEAD/tree/trunk/src/org/opendino/modules/problems/ContinuousMOTestProblems.java ==References== - 30cae2c327fabed8eba00d89e82f000878664d4b 256 254 2019-04-07T16:29:40Z Admin 1 /* Module Description */ wikitext text/x-wiki ==Summary== The module <code>ContinuousMOTestProblems</code> contains a set of multi-objective optimization problems, which can be used to test optimization algorithms. ==Properties== ===General=== {| class="wikitable" style="text-align:left" border="2" cellpadding="5" cellspacing="5" |- ! Algorithm | deterministic test function |- ! Design Variables | continuous design variables only |- ! Objectives | multi-objective for minimization |- ! Constraints | none |- ! Boundaries | problem dependent |- ! Initial Search Region | problem dependent |- ! Typical X | not set |- |} ===Connections=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Starting at his module | none |- ! Ending at this module | Connections of type <code>optimization</code> |- |} ===Actions=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Name !! Description |- ! - | - |- |} ===Options=== The options are the number of discrete and continuous variables and an optional time delay for per evaluation. ==Module Description== === Multi-Objective Sphere === The multi-objective sphere function '''f''' is a set of quadratic functions. More precisely, each ''f<sub>i'' is computed as the square of all continuous variables. ''f_i''('''x''') = (''x_i'' - 1)² + sum_{''j, j~=i''} (x_''j''²) For example ''f₁''('''x''') = (''x₁'' - 1)² + ''x''₂² + ''x''₃<sup>2 + ... ''f₂''('''x''') = ''x₁''² + (''x₂'' - 1)² + ''x''₃<sup>2 + ... ... The Pareto front for the two-objective case is given in the following picture: {| | [[Image:moo_sphere_ds.png|100x100px|center|thumb|300x300px|Design space]] | [[Image:moo_sphere.png|100x100px|center|thumb|300x300px|Objective space]] |} ==Usage== - ==Source Code== https://sourceforge.net/p/opendino/code/HEAD/tree/trunk/src/org/opendino/modules/problems/ContinuousMOTestProblems.java ==References== - 215400b8e149da1137f4df77efdfbf48ea29ab11 6 59 251 2019-04-07T13:49:03Z Admin 1 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 253 251 2019-04-07T16:13:08Z Admin 1 Admin lud eine neue Version von [[Datei:Moo sphere.png]] hoch wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 6 60 255 2019-04-07T16:27:25Z Admin 1 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 12 257 16 2019-04-24T21:03:33Z Admin 1 Admin verschob die Seite [[Documentation/Modules/OptAlgSIMPLEX]] nach [[Documentation/Modules/OptAlgSimplex]] wikitext text/x-wiki ==Summary== This optimization module is an implementation of the popular Nelder-Mead Simplex Algorithm (1965) [[#NelMead | (1)]]. The SIMPLEX method is a standard direct, deterministic optimization algorithm, which is implemented in many numerical tools (e.g. as method <code>fminsearch.m</code> in the MATLAB(R) optimization toolbox or in [http://www.gnu.org/software/octave/ GNU Octave]). A good introduction is given by Wright [[#Wright | (2)]]. The algorithm works best for a small number of design variables (1-10, sometimes 1-20). It fails, for example, on the Rosenbrock function, if more than 10 design variables are given. ==Properties== ===General=== {| class="wikitable" style="text-align:left" border="2" cellpadding="5" cellspacing="5" |- ! Algorithm | deterministic |- ! Design Variables | Written for continuous variables. Discrete or mixed variables are NOT possible. |- ! Objectives | single-objective for minimization. |- ! Constraint handling | no |- ! Boundary handling | no |- ! Initialization | Requires at least one of the following: initial solution, initial search region, or bounds. |- |} ===Connections=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Starting at this module | Module requires exactly one connection of type <code>optimization</code>. |- ! Ending at this module |- |} ===Actions=== {| class="wikitable" style="text-align:left" border="1" cellpadding="5" cellspacing="0" |- ! Name !! Description |- ! '''Run''' | starts the optimization. |- |} ===Options=== The options are currently described as "pop-up help". ==Module Description== The SIMPLEX algorithm is implemented using the paper of Wright [[#Wright | (2)]]. However, some extensions are made as e.g. the initialization is not given in the references. === Initialization === First, an initial simplex is generated. Here, a [http://en.wikipedia.org/wiki/Simplex simplex] is a body in the N-dimensional design space that has N+1 vertices. The vertices are connected by straight lines. For two (N=2) and three (N=3) design variables, a simplex is a triangle or tetrahedron, respectively. If the optimization problem provides an initial solution, this point is taken as first vertex of the simplex. If not, the initial simplex gets a random position obeying certain rules. We distinguish several cases, depending on the problem properties (<code>initial solution, initial search region, bounds</code>). {| border="1" cellspacing="0" ! colspan="3" | Problem Properties Given? || Action |- | <code>initial solution</code> || <code>initial search region</code> || <code>bounds</code> || |- |Yes || No || No || option <code>Initial Size of the Simplex</code> defines the absolute length of the simplex in each design variable direction. I.e. a simplex is constructed, such that the distance between each vertex and the plane generated by the remaining points has this length. |- |Yes or No || Yes || Yes or No || option <code>Initial Size of the Simplex</code> defines the relative length of the simplex in each design variable direction compared to the size of the initial search region (i.e. difference upper to lower limit). Bounds are ignored. |- |Yes or No || No || Yes || option <code>Initial Size of the Simplex</code> defines the relative length of the simplex in each design variable direction compared to the size of the bounds (i.e. difference upper to lower limit). |} === Optimization === The SIMPLEX method follows a deterministic procedure. Except the initialization, always one new point is generated and evaluated. Thus, parallelization is not implemented. ==Usage== ... todo ==Source Code== ToDo:Link to SVN ==References== <span id="NelMead">1</span> Nelder, J. A. and Mead, R. "A Simplex Method for Function Minimization." Comput. J. 7, 308-313, 1965. <span id="Wright">2</span> M. H. Wright. "Direct search methods: once scorned, now respectable". In D. F. Griffiths and G. A. Watson, editors, Numerical Analysis 1995 (Proceedings of the 1995 Dundee Biennial Conference in Numerical Analysis), pages 191–208. Addison Wesley Longman, 1996. 0 61 258 2019-04-24T21:03:33Z Admin 1 Admin verschob die Seite [[Documentation/Modules/OptAlgSIMPLEX]] nach [[Documentation/Modules/OptAlgSimplex]] wikitext text/x-wiki #WEITERLEITUNG [[Documentation/Modules/OptAlgSimplex]] a52ad1692c9595423bce9b3e192cdd2f9bc3cbe4 0 11 259 185 2019-04-24T21:04:16Z Admin 1 wikitext text/x-wiki '''Modules''' contain all the functionality for optimizing and learning. One '''Modules''' may contain an optimization algorithm, an artificial neural network, or a problem to optimize. Here is a list of documented modules in OpenDino. Further modules may exist, but may not yet be documented. == Single Objective Optimization Algorithms == === Indirect, Deterministic Algorithms === Indirect algorithms use gradient or higher order derivative information in the optimization. Not implemented, yet. === Direct, Deterministic Algorithms === These algorithms neither use gradient information nor stochastic processes. * [[Documentation/Modules/OptAlgSimplex | <code>OptAlgSimplex</code>]]: Nelder-Mead Simplex Algorithm === Indirect, Stochastic Algorithms === These algorithms do not use gradient information but require stochastic processes (i.e. random numbers) in their search. * Evolutionary Algorithms ** [[Documentation/Modules/OptAlgOpO|<code>OptAlgOpO</code>]]: 1+1 Evolution Strategy with 1/5 Success Rule: the (1+1)-ES ** [[Documentation/Modules/OptAlgCMA|<code>OptAlgCMA</code>]]: A Multi-member Evolution Strategy with Covariance Matrix Adaptation: the CMA-ES == Single and Multi-Objective Optimization Algorithms == === Indirect, Stochastic Algorithms === * Evolutionary Algorithms ** [[Documentation/Modules/OptAlgMoCMA | <code>OptAlgMoCMA</code>]]: Elitist Evolution Strategy with Covariance Matrix Adaptation * Particle Methods ** [[Documentation/Modules/OptAlgMOPSO | <code>OptAlgMOPSO</code>]]: Particle Swarm Optimization Algorithm == Design of Experiments == * [[Documentation/Modules/DoePlanner | <code>DoePlanner</code>]]: A Module Containing Different DoE plans * [[Documentation/Modules/RandomSampling | <code>RandomSampling</code>]]: Uniform Random Sampling (Monte Carlo) == Optimization in General == * [[Documentation/Modules/BoundHandler | <code>BoundHandler</code>]]: For Optimization Algorithms without Bound Handling * [[Documentation/Modules/ConstraintHandler | <code>ConstraintHandler </code>]]: For Optimization Algorithms without Constraint Handling == Optimization Problems == * [[Documentation/Modules/ProblemSimple | <code>ProblemSimple</code>]] A Simple Test Problem * [[Documentation/Modules/ContinuousTestProblems | <code>ContinuousTestProblems </code>]]: A Set of Single Objective Test Problem * [[Documentation/Modules/ContinuousMOTestProblems | <code>ContinuousMOTestProblems </code>]]: A Set of Multi-Objective Test Problem * [[Documentation/Modules/ProblemTruss | <code>ProblemTruss </code>]]: The goal is to opzimize the thickness of 10 trusses. The weight of the truess, maximum stress, and displacement can each be set either as objective or constraint. == Machine Learning == * [[Documentation/Modules/NeuralNetwork | <code>NeuralNetwork</code>]]: Artificial Neural Network == Miscellaneous Modules == * [[Documentation/Modules/SurrogateManager | <code>SurrogateManager</code>]]: A Framework for Surrogate Managing 92e9e2b9a74e19514640f044d865691b65d0da58